ISO20000 GuiaCompletadeAplicacion LuisMoran PDF

ISO/IEC 20000.
Guía completa de aplicación

para la gestión de los servicios
de tecnologías de la información
Título: ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Telefónica, S.A.
Coordinador: Luis Morán Abad
© AENOR (Asociación Española de Normalización y Certificación), 2009

Todos los derechos reservados. Queda prohibida la reproducción total o parcial en cualquier soporte,
sin la previa autorización escrita de AENOR.
© Crown copyright 2007 All rights reserved. Material is reproduced with the permission of the Office of
Government Commerce under delegated authority from the Controller of HMSO.
Licensed Product
ITIL® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and
other countries.
The Swirl logo™ is a Trade Mark of the Office of Government Commerce.
The OGC logo® is Registered Trade Mark of the Office of Government Commerce in the United Kingdom.
PRINCE® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and
other countries.
IT Infrastructure Library® is Registered Trade Mark of the Office of Government Commerce in the United
Kingdom and other countries.
M_o_R® is Registered Trade Mark of the Office of Government Commerce in the United Kingdom and
other countries.
ISBN: 978-84-8143-662-4
Depósito Legal: M-47292-2009
Impreso en España - Printed in Spain
Edita: AENOR
Maqueta y diseño de cubierta: AENOR
Imprime: Xxxxxx
Nota: AENOR no se hace responsable de las opiniones expresadas por los autores en esta obra.
Génova, 6. 28004 Madrid • Tel.: 902 102 201 • Fax: 913 103 695
comercial@aenor.es • www.aenor.es
Este libro está dedicado a todos los
profesionales de tecnologías de la
información y las comunicaciones que
abnegadamente han aportado sus
conocimientos y experiencia para la definición
y difusión de las normas y las mejores
prácticas que marcan el camino
de evolución de este sector.
Agradecimientos
Este libro recopila las experiencias de profesionales que están fuertemente involu-
crados en el impulso de las normas y las buenas prácticas internacionales relativas a
la gestión de las tecnologías de la información y las comunicaciones.
En la creación de esta primera edición del libro han participado:
• Dirección de la obra (Telefónica):
Luis Morán Abad – Dirección técnica y contenido final.
Alejandro Pérez Sánchez – Contenido intermedio.
• Autores principales (Telefónica):

Luis Morán Abad
Alejandro Pérez Sánchez
Juan Trujillo Gaona
David Bathiely Fernández
Miguel José González-Simancas Sanz
• Colaboradores:
Paloma García López (AENOR)
Carlos Manuel Fernández Sánchez (AENOR)
Eduardo Méndez Polo (Telefónica)
Jaime Pastor Pastor (Telefónica)
8 ISO/IEC 20000. Guía completa de aplicación para la gestión de los servicios de tecnologías de la información
Tomás Hernández López (Telefónica)

Carmen Fernández Prieto (Telefónica)
María Luisa López de Castro (Telefónica)
Julio Morilla Padial (Telefónica)
Andrés Leiva Araos (Telefónica)
Ronaldo Gonçalves Tiago (Telefónica)
Julio José Ballesteros García (Quint Group)
Luis Miguel Rosa Nieto (EXIN España)
Pablo Castro Montero
(Entre paréntesis se indica la empresa en la que trabajaban a fecha 01.01.2009.)
• El control independiente de idoneidad técnica de los contenidos está avalado

por profesionales de itSMF España y de AENOR, junto con otros profesio-
nales independientes:
Carlos López Alonso (Hewlett-Packard) por itSMF España
Antonio José Rodríguez (Quint Group) por itSMF España
Ana Ramos (British Telecom) por itSMF España
Leopoldo Martínez-Osorio del Río (INDRA) por itSMF España
Carmen Caballero (INDRA) por itSMF España
Manuel Fernando Juan Martínez (Banco de Santander)
Julio González Sanz
Boris Delgado Riss (AENOR)
Agradecer también a la dirección de Sistemas de Información de Telefónica que de

forma directa ha hecho posible esta publicación:
María Fernanda Torquati (Telefónica)
José María Tavera Más (Telefónica)
Fabriciano Gangoso Alonso (Telefónica)
Isidro Abad Gosalvez (Telefónica)
Índice
Presentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Capítulo 1. El camino a la excelencia ya existe . . . . . . . . . . . . . . . . . . . . . 21

1.1. Las Normas ISO/IEC 20000 son parte del camino a la excelencia . . . . . 23
1.2. Normas, estándares, marcos de referencia y metodologías reconocidas
en el ámbito de las TI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3. Entender los entornos de normalización y certificación . . . . . . . . . . . . . . 27
1.4. Las principales normas y buenas prácticas en TI . . . . . . . . . . . . . . . . . . . 37
Capítulo 2. Entender las Normas ISO/IEC 20000 . . . . . . . . . . . . . . . . . . . 51

2.1. Introducción a las Normas ISO/IEC 20000 . . . . . . . . . . . . . . . . . . . . . . 53
2.2. Objeto y campo de aplicación de ISO/IEC 20000 . . . . . . . . . . . . . . . . . 65
2.3. La estructura de las Normas ISO/IEC 20000 . . . . . . . . . . . . . . . . . . . . . 70
2.4. Relación entre ISO/IEC 20000 e ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Capítulo 3. El Sistema de Gestión del Servicio de TI (SGSTI) . . . . . . . . . . . . 79

3.1. El sistema de gestión de tecnologías de la información . . . . . . . . . . . . . . 83
Capítulo 4. Planificación e implementación de la gestión del servicio . . . . . 107

4.1. Cómo planificar e implementar la gestión del servicio . . . . . . . . . . . . . . 111
Capítulo 5. Planificación e implementación de nuevos servicios o de

servicios modificados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.1. El proceso de planificación e implementación de nuevos servicios o de
servicios modificados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Capítulo 6. Procesos de provisión de servicio . . . . . . . . . . . . . . . . . . . . . . . 191

6.1. Gestión de nivel de servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
6.2. Generación de informes del servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
6.3. Gestión de la continuidad y disponibilidad del servicio . . . . . . . . . . . . . . 279
6.4. Elaboración de presupuestos y contabilidad de los servicios de TI . . . . . . 331
6.5. Gestión de la capacidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
6.6. Gestión de la seguridad de la información . . . . . . . . . . . . . . . . . . . . . . 403
Capítulo 7. Procesos de relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449

7.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
7.2. Gestión de las relaciones con el negocio . . . . . . . . . . . . . . . . . . . . . . . . 457
7.3. Gestión de suministradores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Capítulo 8. Procesos de resolución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535

8.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
8.2. Gestión del incidente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
8.3. Gestión del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Capítulo 9. Procesos de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619

9.1. Gestión de la configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
9.2. Gestión del cambio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661
Capítulo 10. Procesos de entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693

10.1. Gestión de la entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
Capítulo 11. La certificación conforme a ISO/IEC 20000 de la gestión

del servicio de TI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
11.1. La primera certificación conforme a ISO/IEC 20000 . . . . . . . . . . . . . . 737
11.2. Evidencias y registros importantes en una certificación . . . . . . . . . . . . . 751
Índice 11
Bibliografía y referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
Términos y definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767

Presentación
Las tecnologías de la información son cada día más necesarias en la gestión de las
empresas.
Este sector, en su evolución hacia la madurez, ha ido generando diversos conjuntos
de mejores prácticas que ayudan a las organizaciones a gestionar estos entornos tec-
nológicos cada vez más complicados y, por otra parte, más esenciales.
Este libro nace con la intención de ayudar a todo tipo de empresas en la gestión
de la actividad de sus departamentos informáticos. Profesionales de Telefónica y de
AENOR han puesto su mejor empeño en explicar y aportar sus años de experien-
cia en este ámbito. Para ello, se ha utilizado como eje vertebrador las Normas
UNE-ISO/IEC 20000, que se enriquecen con las buenas prácticas de otros marcos
como ITIL®.
Los autores han desarrollado una buena guía sobre la forma de incorporar estas
mejores prácticas de la industria en la gestión diaria de las tecnologías. Esta publi-
cación ayudará a las empresas a adoptar los últimos avances en la forma de organizar
las actividades que contribuyen a que el mundo tecnológico sea operativo y rentable
para las organizaciones y para la sociedad.
Esperamos que todo su contenido sea de gran utilidad en la mejora de los servicios
de tecnologías de la información prestados en su organización.
Telefónica
Introducción
Durante la década de los años 50, algunas predicciones futuristas imaginaron que,
para el año 2000, los coches serían capaces de volar, se iría de vacaciones a Marte, y
que Estados Unidos podría llegar a contar con “nada menos” que trescientos mil
ordenadores. En 1947 el director de una famosa multinacional del sector predijo
que en el mundo sólo habría mercado para 5 ordenadores. Estas predicciones hoy
en día nos parecen ridículas, unas por lo exageradas, y otras por que se han que-
dado muy cortas.
Las tecnologías de la información y las comunicaciones han avanzado mucho más
de lo esperado, pero después de poblar el mundo de dispositivos de silicio, con
unas capacidades de proceso inimaginables, nos encontramos con un panorama
desalentador:
• Equipos que se bloquean.
• Sistemas que se “caen”.
• Servicios que se interrumpen.
• Atención al usuario deficiente.
• Pérdidas de tiempo y de productividad de los usuarios.
• Personal técnico desbordado por llamadas y peticiones de asistencia.
• Directores de sistemas de información que ven cómo, a pesar del esfuerzo con-
tinuo de su equipo, el roce y el malestar con el resto de la empresa no cesan.
Por ello, no es de extrañar que encontremos frecuentemente que los departamentos

de las tecnologías de la información (TI) se consideren más una carga que una
ayuda para el negocio.
La dinámica industria de tecnologías de la información y las comunicaciones

(TIC), que es capaz de duplicar la capacidad de proceso y de almacenamiento cada
año y medio, lleva desarrollando, en paralelo al avance tecnológico, metodologías
de trabajo que van ofreciendo soluciones de gestión a estos retos planteados. El sec-
tor de las TIC ha ido creando distintas disciplinas para cubrir algunas de las facetas
que necesita la gestión global de las TIC en la empresa. Soluciones que no siempre
se han aplicado con el ahínco y el rigor necesarios.
Parece lógico que los organismos de normalización internacionales, como ISO (Inter-
national Organization for Standardization, Organización Internacional de Normaliza-
ción) e IEC (International Electrotechnical Commission, Comisión Electrotécnica
Internacional), propicien la elaboración de normas que van consolidando las prácti-
cas establecidas relativas a la organización del trabajo en las áreas de TI. Además,
estos organismos de normalización disponen de mecanismos de trabajo asentados
que garantizan una amplia participación de los agentes del sector de las TIC. Este es
el caso de las Normas ISO/IEC 20000, partes 1 y 2, y sus traducciones oficiales al
castellano, publicadas por AENOR como Normas UNE-ISO/IEC 20000 1 en junio
de 2007. El presente libro se centra en explicar la aplicación de estas dos normas.
Las Normas ISO/IEC 20000 definen los procesos y las actividades esenciales para
que las áreas de TI puedan prestar un servicio eficiente y alineado con las necesida-
des de la empresa u organización. Estas normas, construidas sobre la base del
modelo ITIL, se centran principalmente en la ordenación de las disciplinas de
soporte y provisión de servicios de TI. Son normas específicas para la gestión de los
servicios que ofrecen las áreas o los proveedores de tecnologías de la información.
Las Normas ISO/IEC 20000 no son de índole técnico, ni tecnológico. En ellas se
describen los principales flujos de actividades (agrupados en forma de procesos) cuyo
fin es lograr una entrega efectiva y con la calidad requerida de los servicios a los clien-
tes y usuarios. Además, definen un sistema reconocido y probado de gestión que per-
mite a los proveedores de TI (ya sean áreas internas u organizaciones externas) plani-
ficar, gestionar, entregar, monitorizar, informar, revisar y mejorar sus servicios.
Objeto del libro

Este libro se centra en explicar y facilitar la comprensión de las Normas ISO/IEC
20000 con un enfoque práctico, para que su implantación resulte efectiva en
1 Para facilitar la lectura, en el resto del libro se ha optado por utilizar el mismo término
“ISO/IEC 20000” para referirse a estas normas, tanto para la serie UNE, como para la serie
ISO/IEC.
Introducción 17
cualquier tipo de organización que provea servicios de tecnología, tanto interna-

mente a su organización como externamente al mercado, tanto en grandes orga-
nizaciones como en pequeñas o medianas empresas.
Este libro va dirigido a todos los profesionales del ámbito de las tecnologías de la
información y las comunicaciones que estén involucrados en la provisión de servi-
cios. Resultará imprescindible tanto a los responsables de su gestión, como a cual-
quier otro profesional de TI: dirección, gestores, responsables de procesos, consul-
tores, técnicos, personal de soporte, etc.
Al avanzar en este libro, el lector constatará que la industria ya ha normalizado
gran parte del conjunto de actividades necesarias para que los servicios propor-
cionados por las TI sean fiables y eficientes. Cubren desde las actividades del día
a día inmediato, como es la atención a los incidentes y peticiones, hasta la defi-
nición de una estrategia que permita continuar prestando los servicios en caso
de catástrofe, todo ello, sin olvidar conceptos como la planificación o la mejora
continua.
Persiguiendo este fin último de utilidad, los contenidos de cada apartado, además
de incluir íntegramente la norma, se han enriquecido con otras buenas prácticas
ITIL y con la amplia experiencia profesional de los autores.
Por tanto, este libro pretende ser una guía completa de aplicación, una ayuda y una
razonable interpretación de estas normas. No pretende sentar “jurisprudencia” al
respecto. Los autores dan por hecho que puede haber otras formas de aplicar o
interpretar las directrices de las normas, ya que las particularidades de cada negocio
y organización tienen gran influencia.
Estructura del libro

Se ha puesto énfasis en que los contenidos ayuden a la transformación real y per-
ceptible de la gestión de las TI en toda empresa que se inicie en el camino de la apli-
cación de ISO/IEC 20000.
El capítulo 1 “El camino a la excelencia ya existe”, introduce al lector en las nue-
vas tendencias de gestión de las TI, como son: la orientación a procesos, la cali-
dad, las normas y las mejores prácticas. La intención del capítulo es presentar el
amplio, y cada vez más complejo, entorno normativo y de mejores prácticas. Se
conocerá quiénes son los principales actores en estos ámbitos y se tendrá una
primera aproximación de cómo se posiciona cada norma o iniciativa. Este capí-
tulo es un paso previo, que proporciona una visión general de todo este escena-
rio internacional, antes de zambullirse en las especificidades de las Normas
ISO/IEC 20000.
El capítulo 2 “Entender las Normas ISO/IEC 20000” las posiciona en el ámbito

global de las TIC, para pasar después a explicar su alcance, su estructura, sus coin-
cidencias y las principales diferencias frente a ITIL. Este capítulo resulta esencial
para entender adecuadamente los siguientes.
Para facilitar la comprensión, el núcleo central del libro, desde el capítulo 3 al 10,
se organiza siguiendo una estructura de capítulos y numeración de apartados para-
lela a las normas de referencia. En la figura I.1 se muestra este paralelismo inten-
cionado.
El capítulo 3 “El Sistema de Gestión del servicio de TI (SGSTI)”, explica este con-
cepto que suele resultar nuevo para los profesionales de las TIC no acostumbrados
a los sistemas de gestión definidos en la normativa de calidad ISO. Explica con
detalle la creación de un sistema de gestión aplicado a la provisión y soporte del
servicio de tecnologías de la información. Este sistema de gestión constituye en sí
mismo el diseño de las nuevas formas de hacer que transformarán el servicio de TI.
Su utilización ofrece un valor añadido y permitirá alcanzar una posición diferencial
a las organizaciones que lo implementen.
En el capítulo 4 “Planificación e implementación de la gestión del servicio”, se trata
la implantación de las Normas ISO/IEC 20000. Explica la forma de organizar y lle-
var a cabo esta transformación que suponen las nuevas formas de hacer, acordes con
estas normas y definidas en el sistema de gestión. Se explican los aspectos que hay
que tener en cuenta previos a la implantación, para entrar posteriormente en el ciclo
de mejora continua. Se sigue el enfoque a las cuatro etapas del ciclo de mejora con-
tinua (PDCA, de Deming o de Shewhart), que también se explica en este capítulo.
Los capítulos del 5 al 10 se corresponden con los principales procesos identificados
en la gestión del servicio relativos a: creación, provisión, relaciones, resolución,
control y entrega del servicio.
En el libro, también se ha considerado que las empresas, además de mejorar sus ser-
vicios de TI, quieren obtener una certificación que les acredite ante su Dirección o
ante sus clientes de la conformidad de su gestión frente a los requisitos de estas nor-
mas de referencia. A este respecto, el capítulo 11 es una guía que explica el proceso
habitual para obtenerla.
El libro se ha preparado para que se pueda leer en tres recorridos diferentes:
• Recorrido 1: lectura rápida. Paso rápido por los conceptos del libro, sin
profundizar en los procesos. Este recorrido pasa por la lectura de los capítu-
los 1, 2 y 3 en detalle, pues contienen conceptos y posicionamientos que
nadie debería descartar. A partir de este punto, el resto de los capítulos y pro-
cesos tienen su introducción y gráficos que resumen los principales concep-
tos que todo involucrado en las TI debería conocer.
Introducción 19
Índice de las Normas ISO/IEC 20000 Índice del libro ISO 20000
1 Objeto y campo de aplicación 0 Introducción
2 Términos y definiciones 1 El camino de la excelencia ya exite
2 Entender las normas ISO/IEC 20000
3 Requisitos de un sistema de gestión 3 El Sistema de Gestión del Servicio de TI (SGSTI)
4 Planificación e implementación de la gestión del servicio
5 Planificación e implementación de nuevos servicios o de servicios modificados
6 Procesos de la provisión del servicio

6.1 Gestión de nivel de servicio
6.2 Generación de informes del servicio
6.3 Gestión de la continuidad y disponibilidad del servicio
6.4 Elaboración de presupuesto y contabilidad de los servicios de TI (gestión financiera de TI)
6.5 Gestión de la capacidad
6.6 Gestión de la seguridad de la información
7 Procesos de relaciones
7.1 Generalidades
7.2 Gestión de las relaciones con el negocio
7.3 Gestión de suministradores
8 Procesos de resolución
8.1 Antecedentes
8.2 Gestión del incidente
8.3 Gestión del problema
9 Procesos de control
9.1 Gestión de la configuración
9.2 Gestión del cambio
10 Proceso de entrega
10.1 Proceso de gestión de la entrega
11 La certificación conforme a ISO/IEC 20000

de la gestión del servicio de TI
11.1 La primera certificación conforme
a ISO/IEC 20000
11.2 Evidencia y registros importantes en una
certificación
Bibliografía 12 Bibliografía y referencias
13 Términos y definiciones
Figura I.1. La estructura del libro transcurre paralela

a las Normas ISO/IEC 20000
• Recorrido 2: lectura secuencial y a fondo. De principio a fin, que es la

recomendada por los autores.
• Recorrido 3: manual de consulta. La estructura del libro con temática
independiente permite utilizarlo también como manual de consulta, acce-
diendo directamente a cada proceso.
1 El camino a la excelencia
ya existe
Capítulo 1
1.1. Las Normas ISO/IEC 20000 son parte del camino a la excelencia
1.2. Normas, estándares, marcos de referencia y metodologías reconocidas
en el ámbito de las TI
1.3. Entender los entornos de normalización y certificación
1.4. Las principales normas y buenas prácticas en TI
0
50
38
BIT
MI CO
CM
0 1
ITIL 2 70
0 00 000
9 20
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
1. El camino a la excelencia ya existe 23
1.1. Las Normas ISO/IEC 20000 son parte del

camino a la excelencia
Comparando la gestión habitual de las tecnologías de la información con otras
áreas de la empresa, podremos encontrar que, en las más avanzadas, existen mode-
los de gestión firmemente establecidos que las hacen parecerse al modelo de una
orquesta sinfónica en la que, si bien cada músico es un excelente especialista en su
instrumento, es en la interpretación del concierto cuando la orquesta demuestra su
auténtico valor actuando como un todo.
En cambio, las áreas que gestionan sistemas tecnológicos han puesto tradicional-
mente el foco en el conocimiento y dominio de la tecnología. Es esencial y obvio
que se necesitan buenos técnicos para el diseño, la construcción y el mantenimiento
del hardware y del software. Sin embargo, la situación actual refleja que el control
de la técnica, aunque totalmente imprescindible, no es suficiente para satisfacer
todo lo que la empresa demanda de las áreas de TI. Queda una importante asigna-
tura pendiente que, por más que se invierta en tecnología y en técnicos, no se con-
sigue resolver: actuar perfectamente engranados, todos juntos y bien coordinados
para conseguir un fin común: ser cada vez más eficientes en costes y capaces
de evolucionar con la agilidad típica del “ecosistema” Internet (objeto de deseo de
todos los negocios para sus áreas de TI).
Los responsables de los departamentos de TI deben responder a importantes des-
afíos: la eficiencia en costes, la calidad, el cumplimiento de plazos, la agilidad y la
satisfacción de los clientes y usuarios están entre ellos. La gestión de las TI debe
evolucionar desde los modelos artesanales hacia formas de hacer más industrializa-
das. Implementar formas de trabajo repetibles, mejorando la calidad de lo cons-
truido, la fiabilidad de los servicios o aumentando la capacidad de “producción” de
la organización, todo ello, dentro de un nuevo entorno más fluido en las relaciones
y que genere menos estrés en las personas. En esta evolución, las buenas prácticas
sectoriales recogidas en las Normas ISO/IEC 20000, en los libros ITIL, en otras
normas y marcos de referencia, marcan el camino a recorrer para alcanzar la exce-
lencia en la gestión de las TI.
Del mismo modo que un abogado debe conocer las leyes para ejercer su profesión,
o un arquitecto la legislación y reglamentación sobre urbanismo y edificación; la
dirección y los profesionales de los departamentos de TI deben conocer con detalle
el conjunto de buenas prácticas, normas o estándares que se están consolidando en
su propio sector. La actividad de los directivos y profesionales de las TI, debe pasar
por conocer con detalle la normativa y marcos de las mejores prácticas aceptados
por el mercado, para aplicarlas posteriormente en su organización. Este es un buen
camino para la mejora de las actividades.
1.2. Normas, estándares, marcos de referencia

y metodologías reconocidas en el ámbito
de las TI
El mundo de la ciencia está empeñado en la búsqueda de una ley universal que sea
válida tanto para el mundo del átomo como para las grandes galaxias. De manera
análoga, en el ámbito de las TI todavía no se ha conseguido definir un modelo for-
mal universal de toda su actividad que contemple desde la más detallada tarea téc-
nica, hasta la definición al más alto nivel de la estrategia alineada con el negocio.
El interés por mejorar las actividades de las TI ha hecho que se hayan ido desarro-
llando varios marcos o modelos que cubren las principales parcelas de la gestión y
del conocimiento. A veces son complementarios entre sí, en otros aspectos se sola-
pan y, con frecuencia, presentan enfoques distintos sin ofrecer una integración clara
con otros modelos o aproximaciones. A pesar de ello, es indudable la utilidad de
trabajar con éstos modelos de referencia ya definidos y los beneficios que aportan a
las organizaciones que los utilizan como base para avanzar.
Una buena representación que permite realizar una primera aproximación a este
mundo en ebullición de normas, modelos y marcos de referencia, es la realizada por
la consultora Gartner Group, presentada en la figura 1.1. En ella, se posicionan las
normas en función de dos conceptos: el ámbito de aplicación y el tipo de uso de la
normativa. El ámbito de aplicación de las normas ocupa las columnas de la tabla y
se divide en dos alcances: el general de la empresa y las disciplinas específicas de TI
(gobierno de TI, gestión del servicio de TI, funciones de TI y tecnología). El tipo
de uso de la normativa se representa en tres filas: normativa con foco en la evalua-
ción de la actividad, directrices y mejores prácticas, y la normativa de carácter más
prescriptivo. La tabla original de Gartner se ha actualizado con la contribución de
los autores, incorporando nuevas normas y marcos de referencia, como: ITIL v3,
CMMI for Services, ISO/IEC15504, ISO/IEC 38500, ISO 9004, ISO14001, ISO
90003, ISO/IEC 27001, PRINCE2, ISPL, ASL y DSDM). La dinámica de este
sector hará que en breve aparezcan nuevas normas y estándares para incorporar a
éste gráfico.
Entre estos modelos o recomendaciones destacan las Normas ISO/IEC 20000,
que compiten por un reconocimiento en este campo. El hecho de llegar con el res-
paldo de los organismos de normalización internacionales, es un claro empuje para
que se asiente como un referente en la sociedad. Como además, se han publicado
también como norma nacional en muchos países, cumplen todo lo necesario para
que los gobiernos puedan incluirlas en sus legislaciones o regulaciones (pudiendo
llegar a convertirse en obligatorias).
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
Ámbito de la empresa
p Ámbito específico
p de TI
Calidad
Gestión del Funciones de TI
y medio Empresa Gobierno TI Tecnología
servicio de TI ((desarrollo,, seg.,
g , etc.))
ambiente
Ticket SPICE
Evaluación
SAS
ISO/IEC 15504
8000
TQM PPeople
l ISO/IEC
King CMMI for
CMMI 17799 o
COBIT Services
ACC 27002 FEAF
CMMI ISO
ITIL v3
ISO ISO/IEC
CoCo ASL 90003
Tipo de usso
9001 ISO ITIL v2 ISO TOGAF

es
SO 27001
Directrice
DSDM 12207
EFQM 9004 COSO ISO/IEC
ISO ISO/IEC ISPL BS 25999
eTOM 20000 Zachman
14001 (Telcos) 38500 PAS 77
MOF
SAS 70 PMBOK
Lean
CORBA
Prrescriptivo
6 RUP PRINCE2
Sigma XML
TL 9000 SOX
SOA
Fuente: Gartner y e.p.
Figura 1.1. Mapa de las diferentes normas y marcos de referencia

relacionados con las TI
El veterano marco ITIL destaca como el gran compendio de referencia, que aspira
a convertirse en ese modelo universal que estructura y organiza toda la actividad de
las TI. Si bien la versión 2, publicada en el año 2000, ha tenido una aceptación
excepcional, hay que esperar a ver cómo el sector va adoptando la nueva versión 3,
publicada en el año 2007, y que presenta una visión más amplia y coherente de la
gestión de las TI, agrupada en torno al ciclo de vida del servicio.
El marco para el desarrollo de software CMMI (Capability Maturity Model Integra-
tion) aparece como el modelo más aceptado para la medición de la madurez de los
procesos de gestión en la construcción de aplicaciones. Para complicar más el pano-
rama, en su última versión se crea un nuevo modelo CMMI for Services, que se
superpone en gran medida con el ámbito central de ITIL; y por tanto, también con
las Normas ISO/IEC 20000. Además, para los procesos y medición de la madurez
del desarrollo, también la normativa internacional inició desde 1993 su andadura.
ISO e IEC han desarrollado un modelo para la evaluación de los procesos de desa-
rrollo de software bajo la iniciativa SPICE que ha desembocado en la publicación
de la serie ISO/IEC 15504. En paralelo, han ido evolucionando otro conjunto de
normas relativas a la ingeniería del software (ISO/IEC 15288, ISO/IEC 12207,
ISO/IEC 25001, ISO/IEC 25030, ISO/IEC 16085, etc.).
La gestión de la seguridad de los sistemas de información ha sido una de las áreas

más difundidas en el entorno normativo de las TI, con las normas UNE-ISO/
IEC 27001 (sistema de gestión de seguridad) y UNE-ISO/IEC 17799 (un
código de buenas prácticas para la gestión de la seguridad de la información),
que se ha renumerado como UNE-ISO/IEC 27002. Recientemente han apare-
cido unas normas británicas sobre la gestión de la continuidad de negocio, deno-
minadas BS 25999.
En el ámbito de la auditoría, medición y gobierno de TI el modelo COBIT (Con-
trol Objectives for Information and Related Technology) está reconocido como una
excelente referencia. En relación al gobierno de las TI, la normativa internacional
de ISO ha tomado posiciones con la nueva Norma ISO/IEC 38500 Corporate
Governance of Information Technology (también denominada en sus etapas de borra-
dor como 29382), inspirada en la Norma australiana AS 8015. Como un hijo
menor del modelo COBIT, para la medición del valor que aportan las TI al negocio,
se ha definido un nuevo “sub-marco” denominado ValIT.
En relación a la gestión de proyectos de desarrollo de software, el marco líder es
PMBOK (Project Management Body of Knowledge), una metodología reconocida
por el organismo norteamericano de normalización ANSI. También hay que tener
en cuenta el modelo PRINCE2 (Projects In Controlled Environments) que, reali-
zado por los impulsores de ITIL, es más sencillo que el anterior, y resulta de utili-
dad para proyectos de mejora y de implantación de ITIL o de ISO/IEC 20000.
Otros modelos que se complementan o solapan con los anteriores, aunque con
poca aceptación en el sector de las TI son: en el ámbito de la gestión de proveedo-
res ISPL (Information Services Procurement Library), para disponer de un mapa
completo en la construcción de aplicaciones: ASL (Application Services Library) o
DSDM (Dynamic Systems Development Method).
Por su importancia y universalidad, también hay que tener en cuenta la serie de
normas internacionales ISO 9000, familia de normas y directrices que contienen
los requisitos para la gestión de la calidad general de una organización. Dentro de
esta serie destaca la Norma UNE-EN ISO 9001, que contiene los requisitos del
sistema de gestión de la calidad, también esencial para la implantación de las Nor-
mas ISO/IEC 20000. La Norma UNE-EN ISO 9004 contiene recomendaciones
prácticas para aquellas empresas que quieran ir más allá de los requisitos mínimos
establecidos en UNE-EN ISO 9001.
En el ámbito de la calidad aplicada al desarrollo de software, también hay que consi-
derar la Norma UNE-ISO/IEC 9003 que versa sobre las directrices para la apli-
cación de la Norma UNE-EN ISO 9001 al desarrollo de software. Por otra parte, la
Norma ISO/IEC 12207 proporciona un marco para los procesos, actividades y
tareas relacionadas con el ciclo de vida del software.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
Por otra parte, los temas medioambientales también tienen su impacto en la ges-
tión de TI. Deben tenerse en cuenta: la legislación nacional, local y la normativa
sobre retirada y gestión del equipamiento y residuos informáticos; la serie de Nor-
mas ISO-EN 14000 relativa a la gestión medioambiental; en España existe tam-
bién la Norma UNE 150002 Sistemas de gestión medioambiental. Guía para la apli-
cación de la norma UNE-EN ISO 14001:1996 en las empresas de servicios y la guía para
la aplicación de los sistemas de gestión medioambiental a las relaciones con sumi-
nistradores y clientes, denominada UNE 150004 EX; o el Código de Conducta
para la Eficiencia Energética en Centros de Datos publicado por la Unión Europea.
Tanta abundancia de información y recomendaciones resulta confusa para las orga-
nizaciones que sólo desean soluciones prácticas y directas para mejorar su gestión
de las TI.
De todo el mapa anterior, se recomienda centrarse inicialmente en las normas y
marcos de mayor relevancia y más aceptados para la mejora de TI, como son:
• ISO/IEC 20000 partes 1 y 2, e ITIL (en sus versiones 2 y 3) para mejorar la
gestión de los servicios de TI.
• COBIT para la auditoría y la medición de las TI.
• ISO/IEC 27001 para la gestión de la seguridad de la información.
• ISO/IEC 15504 y CMMI for Development para la gestión del desarrollo de
software.
• ISO/IEC 38500 y COBIT como referencias para el gobierno de las
tecnologías de la información.
1.3. Entender los entornos de normalización y

certificación
Tiene gran interés conocer “quién es quién” en el ámbito de la normalización y la
definición de las buenas prácticas relacionadas con la provisión de servicios de TI.
Concurren en este espacio: organizaciones internacionales y europeas de carácter
multisectorial que producen normas (como ISO, IEC, CEN, CENELEC, ETSI,
UIT), organismos de normalización nacionales (AENOR en España, BSI en UK,
etc.), administraciones públicas e instituciones gubernamentales (como OGC en
UK, DoD en los EEUU), organizaciones privadas (itSMF, ITGI), universidades
(Carnegie Mellon), junto a otros organismos del mundo de la certificación y acre-
ditación de empresas. La figura 1.2 presenta en forma de tabla los principales acto-
res. En las columnas se muestran las instituciones generadoras de normativas y
marcos de mejores prácticas (organismos de normalización internacional, organis-

mos de normalización en cada país y las principales iniciativas de organizaciones
privadas –aunque algunas con el respaldo indirecto gubernamental). Las filas enu-
meran algunos organismos e instituciones. Bajo el concepto de promotor se inclu-
yen quién está principalmente detrás de las iniciativas respaldando a las institucio-
nes. Finalmente se presentan algunas normas y marcos de cada ámbito.
Normalización y acreditación
Normalización internacional Principales iniciativas privadas
según el país
• España: AENOR - ENAC
ISO CEN OGC Carnegie ITGI PMI
• UK: BSI - UKAS
e
• USA: ANSI Mellon

instituciones
IEC CENELEC
Organismos
• Alemania: DIN - TÜV

UIT ETSI • Argentina: IRAM
• Chile: INN
• México: DGN
O
• Perú: INDECOPI
• Australia: SA
Gobiernos Gobierno del país OGC DoD ISACA PMI

es
(UK) (USA) (USA) (USA)

Promotore
Participan comités Participa industria local Participan los líderes y gurús de la industria TI
normalización países itSMF España y GT-25
(en UNE-ISO
UNE ISO 20000) itSMF SEI y ESI
ISO/IEC ISO/IEC
ISO 9001 ISO 27001 ITIL CMMI COBIT PMBOK
20000 20000
ormas
ISO/IEC ISO 17799-

ISO 20000 27001 BS 15000 27002
No
ISO/IEC ISO/IEC BS 25999 Prince2

38500 17799 AS 8015 PAS 77
Fuente: Telefónica
Figura 1.2. Actores en el ámbito de la normalización relacionados con las TI
En el ámbito de la normalización internacional, los organismos de normalización

internacionales (ISO, IEC, UIT) y los europeos (CEN, CENELEC, ETSI) dispo-
nen de procedimientos estables que garantizan la participación de los países miem-
bros y de la industria local. Aunque cada organismo tiene procedimientos específi-
cos para la realización de la normativa, en todos está garantizada la participación de
los países y de sus representantes. Para garantizar la representación se utilizan estruc-
turas de comités, subcomités y grupos de trabajo internacionales, que frecuente-
mente se reflejan en estructuras similares en los países. Por tanto, no hay un ciclo
único para la creación de las normas, aunque todos se basan en la representación de
los organismos de normalización de los países a través de sus miembros nacionales
(AENOR, BSI, DIN, etc.) como instrumento para garantizar la participación
nacional.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
Por otra parte, el ámbito de las denominadas iniciativas privadas (ITIL, CMMI,
COBIT, etc.) se centra principalmente en el desarrollo de marcos de mejores prác-
ticas y no de normativa. Los procedimientos y la gestión de la representación del
sector quedan a la libre elección de la institución u organismo que impulsa la ini-
ciativa (OGC, Carnellie Mellon, ITG, etc.). Con frecuencia se basa en una llamada
pública de participación para trabajar en la siguiente edición de estos marcos a la
que suelen responder los principales actores internacionales y gurús en la materia.
El proceso de selección del equipo de revisión es específico de cada institución, así
como el procedimiento de edición de la nueva versión del marco de referencia.
Como se puede intuir hay que ser un autentico especialista en la materia para com-
prender los diversos esquemas y estructuras que se han ido creando alrededor de la
normalización y marcos de mejores prácticas. Por la vinculación con la temática de
este libro se explican los procesos de creación de las normas ISO/IEC y de las nor-
mas UNE españolas:
Ciclo de creación de las normas ISO/IEC. Una norma internacional se desarro-
lla en el ámbito de los comités técnicos y de los subcomités técnicos de ISO y de
IEC. El proceso sigue seis etapas: propuesta, preparatoria, comité, consulta, apro-
bación y publicación. En este proceso, el documento propuesta de norma pasa por
tres estados que indican el grado de aceptación y apoyo que se va alcanzando de los
diversos borradores:
• CD (Committee Draft): es un borrador generado por un grupo de trabajo,
que ha recibido la aprobación del grupo y se remite al comité correspon-
diente para su aprobación.
• DIS (Draft of International Standard): es el borrador de norma internacio-
nal que el comité de normalización ha aprobado y somete a comentarios y
votación por parte de los países.
• FDIS (Final Draft of International Standard): es el borrador final de la
norma internacional, que el comité envía para su aprobación final a todos los
miembros para su publicación final como norma internacional.
En la etapa 2, o preparatoria, se emite el borrador de la norma en fase CD. En la

etapa 3 se aprueba el borrador para pasar al estado de borrador de comité (DIS)
que será sometido a aprobación en la etapa 4 o de consulta. Así, el borrador apro-
bado pasa al estado de borrador final de norma internacional (FDIS) que será
sometido para su aprobación definitiva en la etapa 5.
Además, existe el procedimiento rápido de aprobación, o fast-track, para documen-
tos con un grado alto de madurez, como es el caso de normas locales que se quie-
ran elevar a internacionales. En este caso, primero se somete a una votación para
aceptar que la nueva norma se cree por el procedimiento de fast-track, para pasar
directamente como DIS a la etapa 4. Normalmente el procedimiento rápido puede
durar un año, mientras que el normal suele durar entre 2 y 3 años, dependiendo de
la dificultad de alcanzar el consenso en las diversas etapas.
Ciclo de creación de las normas UNE españolas. El proceso de elaboración de
una norma UNE está sometido a una serie de fases que permiten asegurar que el
documento final es fruto del consenso, y que cualquier persona, aunque no perte-
nezca al comité de AENOR, productor de la norma, pueda emitir sus opiniones o
comentarios. Tras la aprobación del proyecto final de norma por un Comité Téc-
nico de Normalización, el Boletín Oficial del Estado (BOE) publica la relación
mensual de proyectos UNE sometidos a un período de Información Pública,
durante el cual cualquier persona o entidad interesada podrá presentar observacio-
nes. Las observaciones deben realizarse a AENOR. Una vez analizados los comen-
tarios recibidos en esta fase, el comité redactará el texto final, que será aprobado y
publicado como norma UNE por AENOR.
En la figura 1.3 se representan las etapas de estos dos ciclos, internacional y nacional.
Proceso de elaboración de una Proceso de elaboración de una

norma ISO/IEC internacional norma UNE española
1. Etapa de propuesta 1. Trabajos preliminares

Se elabora la propuesta de norma
2. Elaboración del proyecto de
2. Etapa preparatoria norma en el seno de un Comité
Se consensúa el borrador CD Técnico de Normalización (CTN)
3. Etapa de comité 3. Envío de la norma al BOE
El comité aprueba CD → DIS para información pública
4. Etapa de consulta 4. Elaboración y aprobación por el
DIS se somete a consulta CTN de la propuesta final de norma
5. Etapa de aprobación 5. Aprobación de la propuesta final
Se aprueba DIS → FDIS por AENOR
6. Etapa de publicación 6. Publicación de la nueva
FDIS se edita como norma ISO norma UNE
Fuente: ISO y e.p. Fuente: AENOR
Figura 1.3. Procedimientos de creación de normas internacionales y nacionales
A continuación, se presenta una visión general de los principales actores en este

ámbito normativo que tienen cierta relevancia en la gestión de las TI, aunque no
pretende ser un tratado exhaustivo.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
Organismos de normalización internacionales

ISO (International Organization for Standardization, Organización Internacional
de Normalización). Es el organismo de normalización oficial reconocido a nivel
internacional. Su objetivo es poner a disposición de la industria un catálogo de nor-
mas sobre productos y servicios que se puedan utilizar para dar garantía de unos
niveles de calidad preestablecidos. Fue creado en febrero de 1947 y tiene su sede en
Ginebra. Cuenta en la actualidad con la representación de 153 países. Tiene como
objetivo lograr la coordinación internacional y la unificación de las normas de la
industria. Coopera estrechamente con la IEC.
IEC (International Electrotechnical Commission, Comisión Electrotécnica Interna-
cional). Es la organización internacional centrada en la normalización de los ámbi-
tos eléctrico, electrónico y de tecnologías relacionadas. ISO e IEC cooperan estre-
chamente en campos de interés mutuo, especialmente en el ámbito de las TI en el
que desarrollan normas de forma conjunta, las denominadas ISO/IEC.
UIT (International Telecommunication Union, Unión Internacional de Telecomuni-
caciones). Organismo internacional encargado de la elaboración de recomendacio-
nes para el sector de las telecomunicaciones.
Organismos de normalización europeos

CEN (European Committee for Standardization, Comité Europeo de Normaliza-
ción). Es el organismo espejo de ISO a nivel europeo. Está centrado en la normali-
zación en todos los campos excepto en el eléctrico y en el de telecomunicaciones.
CENELEC (European Committee for Electrotechnical Standardization, Comité
Europeo de Normalización Electrotécnica). Es el organismo espejo de IEC a nivel
europeo. Está dedicado a la normalización en el ámbito eléctrico y electrónico.
ETSI (European Telecommunications Standards Institute, Instituto Europeo de
Normas de Telecomunicación). Organismo equivalente a la UIT para Europa,
cuyo campo de actividad se centra en las telecomunicaciones y comunicaciones
electrónicas.
Organismos de normalización nacionales

AENOR (Asociación Española de Normalización y Certificación). Es el orga-
nismo que desarrolla la actividad de normalización en España. Es una organización
privada, independiente y sin ánimo de lucro, reconocida en los ámbitos nacional,
europeo e internacional para el desarrollo de actividades de normalización y certifi-

cación (N+C) en un ámbito multisectorial. Cuenta en la actualidad con más de 20
centros operativos repartidos en: España, México, Chile, El Salvador, Italia, Portu-
gal, Brasil, Bulgaria, China, etc. Tiene como objetivo contribuir, mediante el des-
arrollo de las actividades de N+C, a mejorar la gestión de la calidad en las empre-
sas, sus productos y servicios, proteger el medio ambiente y, con ello, lograr el
bienestar de la sociedad en su conjunto.
BSI (British Standards Institute). Organismo de normalización del Reino Unido.
Es destacable su actividad en la elaboración de nuevas normas en el ámbito de la
gestión de las TI. Creador de la serie de normas BS 15000, base sobre la que se han
definido las actuales Normas ISO/IEC 20000.
En general, cada país tiene su propio organismo de normalización, entre otros
podemos destacar: DIN en Alemania, AFNOR en Francia, UNI en Italia, SA en
Australia, etc.
Otros organismos de habla hispana, con los que AENOR mantiene una estrecha
colaboración motivada, entre otras cosas, por la traducción conjunta de normas
internacionales al español, son: IRAM en Argentina, INN en Chile, DGN en
México, INDECOPI en Perú, etc.
Los gobiernos
Es importante destacar el papel activo de los gobiernos, instituciones gubernamen-
tales y administraciones públicas en el campo de la normalización, pues desempe-
ñan un triple papel: como sustento de la actividad de normalización mediante sub-
venciones a los organismos de normalización, como impulsores de algunas
iniciativas destacadas, y en su papel de exigir el cumplimiento de la normativa, bien
estableciendo una regulación o bien en su papel de cliente contratante de servicios
al sector de las TIC.
Entre estos organismos destacan el Ministerio de Comercio Británico (OGC, Office
of Government Commerce) en su papel de creador, impulsor y propietario de ITIL y
el Departamento de Defensa de Estados Unidos (DoD, Departament of Defense)
como impulsor de CMMI.
Organismos de acreditación
Las entidades nacionales de acreditación son entidades independientes cuya fun-
ción es la acreditación de entidades certificadoras y laboratorios de ensayo. Es decir,
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
el reconocimiento formal de que una organización es competente para la realiza-

ción de una determinada actividad de evaluación de la conformidad o la realización
de un ensayo determinado.
Las organizaciones que podemos destacar son:
• Internacionalmente: IAF (International Accreditation Forum).
• En Europa: EA (European Cooperation for Accreditation).
• En España: ENAC (Entidad Nacional de Acreditación en España).
• En el Reino Unido: UKAS (United Kingdom Accreditation System).
IQNet. Un papel parecido a la acreditación lo realiza la Red Internacional de Cer-

tificación (IQNet, International Certification Network), asociación formada por las
entidades de certificación líderes en la certificación de empresas en sus respectivos
países. Entre sus objetivos están:
• El reconocimiento y promoción de los certificados expedidos por sus miem-
bros en todos los sectores industriales y de servicios.
• La coordinación de los procesos de certificación de empresas que operan en
distintos países.
Normalmente, los certificados locales emitidos por las entidades certificadoras van
acompañados de el reconocimiento internacional de IQNet.
Entidades certificadoras
Para que las empresas puedan demostrar a nivel nacional e internacional que cum-
plen las normas, necesitan un certificado. Se trata de un instrumento para verificar
la correcta implantación de las normas.
La obtención del certificado se realiza mediante un proceso de evaluación indepen-
diente por parte de una entidad certificadora o de certificación. Un requisito
importante que asegura la solvencia para que una entidad pueda conceder una
marca de certificación es que dicha entidad sea “competente para certificar” los
productos, los servicios, los sistemas de gestión o las personas, a los que se aplica la
marca de certificación.
Los organismos de acreditación son los encargados de acreditar a las entidades de
certificación. Las entidades de certificación utilizan los servicios profesionales
de los auditores.
Marcas de certificación
Las marcas de certificación las conceden las entidades correspondientes a los pro-
ductos, sistemas y servicios que cumplen con los requisitos definidos.
La certificación, en base a normas, tiene su reflejo en los distintivos de certifica-
ción, cuya concesión significa que el producto o servicio ha pasado por el adecuado
proceso de certificación de forma satisfactoria. Cuando, por ejemplo, se trata de
una marca de seguridad, la concesión de la marca significará que cumple los requi-
sitos de seguridad, según la norma de referencia.
En un producto con certificado de calidad, la etiqueta puede contener distintos
logotipos (véase la figura 1.4) dependiendo de la entidad que otorgue el certificado.
Figura 1.4. Ejemplos de marcas de certificación de sistema y de producto

en el caso de AENOR
En el Reino Unido se ha desarrollado una marca de certificación específica para

ISO/IEC 20000, según un acuerdo interno entre UKAS (organismo de acreditación
de ese país) e itSMF-UK (capítulo inglés del itSMF, Information Technology Service
Management Forum), con un reglamento específico (esquema de certificación). Por
el contrario, en la mayoría de los países, la certificación ISO/IEC 20000 transcurre
por los caminos habituales de la certificación del país, con marcas específicas de cada
entidad certificadora, y regulado por el organismo de acreditación del país.
Auditores
Los auditores son los únicos profesionales acreditados para realizar la auditoría del
cumplimiento de los requisitos de una norma por una organización. La calificación
de auditor se concede únicamente a los candidatos que demuestren experiencia
suficiente y hayan pasado los exámenes exigidos para ello.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
En el caso de la Norma ISO/IEC 20000-1, existe una acreditación específica de

auditor otorgada por UKAS e itSMF-UK a profesionales con amplia experiencia,
tras superar un curso en entidades de formación acreditadas y superar el examen al
respecto. Esta acreditación de auditor está vinculada al esquema de certificación
conjunto de UKAS e itSMF-UK.
Consultores
Los consultores asesoran, bien a las organizaciones o entidades que quieren
implantar las normas, o bien, una vez implantadas, que desean certificarse. Para
esta función existe una acreditación profesional específica. La formación que reci-
ben les permite adquirir un nivel suficiente de conocimiento de la normas, del
esquema de certificación y de su aplicación.
Los consultores asisten a las organizaciones en la interpretación y aplicación de la
normas, así como, para la aplicación efectiva de ISO/IEC 20000 en la gestión del
servicio. Asimismo, el consultor externo puede efectuar una evaluación de los nive-
les de gestión del servicio y establecer el nivel de preparación necesario para una
solicitud de certificación y su posterior consecución.
Actualmente, existe una acreditación de consultor ISO/IEC 20000 otorgada por enti-
dades de formación acreditadas por UKAS e itSMF-UK. Otros organismos que regu-
lan la formación profesional (EXIN, APMG) también están entrando en este campo.
Las organizaciones alrededor de ITIL

ITIL (Information Technology Infrastructure Library, Biblioteca de Infraestructuras
de Tecnologías de la Información) es el compendio de las mejores prácticas en la
gestión de TI más extendido y ampliamente aceptado por la industria.
La estrecha relación entre los contenidos de las Normas ISO/IEC 20000 y los
libros ITIL, hace relevante conocer cuáles son los principales miembros de este
“ecosistema” creado para la difusión y evolución de estas prácticas:
OGC (Office of Government Commerce, Oficina de Comercio del Gobierno). Ofi-
cina dependiente del Ministerio de Economía y Hacienda británico, responsable de
un amplio programa para mejorar la eficiencia de las empresas. Este organismo
(antes denominado CCTA) fue el creador de ITIL a finales de los años 80.
TSO. Editorial inicialmente vinculada al entorno gubernamental británico, centrada
en la publicación de libros y documentación producida en este ámbito. Fue privati-
zada en 1996 y ha sido comprada por el grupo Williams Lea en enero de 2007.
TSO se encarga de la publicación impresa y online de los libros ITIL, gestionando

sus derechos de propiedad intelectual.
itSMF International (Information Technology Service Management Forum, Foro
internacional para la Gestión del Servicio de TI). Creado en el Reino Unido en
1991, es una red mundial de grupos de usuarios de TI que ofrecen mejores prác-
ticas y guías basadas en normas para la provisión de servicios de TI. La organiza-
ción internacional coordina las actividades de los capítulos locales y apoya al desa-
rrollo y difusión de las evoluciones de ITIL.
itSMF está presente en países como: Francia, Bélgica, Alemania, Portugal, Nor-
uega, Japón, Brasil, Dinamarca, Austria, Finlandia, Canadá, EEUU, Singapur,
Australia, Italia, Hungría, Rumania, Suecia, Argentina, España, etc.
itSMF España. Capítulo español de itSMF. Constituido como una asociación sin
ánimo de lucro, actúa como una comunidad de usuarios. Centra sus intereses en las
prácticas y metodologías de gestión y gobierno de las TI. Tiene como objetivo ayu-
dar a las organizaciones a adoptar soluciones de gestión de servicios TI e impulsar
la adopción de las mejores prácticas.
Certificación profesional privada en el ámbito de la

gestión del servicio
Alrededor de la difusión de las mejores prácticas de gestión del servicio de TI se
ha ido creando una oferta de servicios de formación para los profesionales, deno-
minadas “privadas” por no tener asociadas un reconocimiento oficial del Estado,
pero muy apreciadas en el mundo empresarial. No se debe confundir esta certifi-
cación individual de profesionales con la certificación de organizaciones o provee-
dores de TI.
En el ámbito de ITIL, las certificaciones profesionales tienen gran tradición. Se ha
evolucionado del esquema anterior de certificaciones de ITIL v2 en tres niveles
(Foundation, Clusters y Service Manager) a uno nuevo en ITIL v3 basado en una
estructura más flexible de cuatro capas: Foundation para los conocimientos gene-
rales iniciales, Intermediate para el conocimiento en más detalle de uno o varios de
los libros del ciclo de vida o de agrupaciones de procesos, ITIL Expert que capacita
para la gestión integral de los servicios que requiere haber realizado un conjunto de
cursos Intermediate e ITIL Master, máximo grado de certificación que ratifica la
capacidad de analizar y aplicar los conceptos ITIL a nuevas áreas. La calidad de las
empresas de formación y el control de los exámenes los gestiona APM Group, a
quién la OGC ha otorgado en 2006 la gestión de la acreditación de la formación
relacionada con la marca ITIL.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
En el ámbito de ISO/IEC 20000, la aparición de estos esquemas de certificación

profesional garantizados es más reciente, destaca la iniciativa de EXIN (Examination
Institute for Information Science), pero posiblemente aparecerán otros, ya que el
entorno de normativa internacional no ejerce el concepto de “propietario de marca”.
1.4. Las principales normas y buenas prácticas

en TI
Las Normas ISO/IEC 20000
Dado que estas normas se tratan en profundidad en el resto del libro, única-
mente se presenta en la figura 1.5 un esquema general de su estructuración en
14 procesos (los 13 procesos descritos en los capítulos 6 al 10 de las normas,
Sistema de Gestión del Servicio de TI (SGSTI)
Planificación e implementación de la gestión del servicio (PDCA)
Planificación e implementación de nuevos servicios o de servicios modificados
Procesos de la provisión del servicio

Gestión de la capacidad Gestión de nivel de servicio Gestión de la seguridad
Gestión de la Generación de de la información
continuidad y informes del servicio Elaboración de
disponibilidad presupuesto y contabilidad
del servicio Procesos de control de los servicios de TI
Gestión de la configuración
Gestión del cambio
Proceso Procesos
de entrega Procesos de relaciones
Proceso de gestión de resolución Gestión de las relaciones
de la entrega Gestión del incidente con el negocio
Gestión del problema Gestión de suministradores
Fuente: UNE-ISO/IEC y e.p.
Figura 1.5. Esquema general de los procesos de ISO/IEC 20000

junto al proceso del capítulo 5 “Planificación e implementación de nuevos servi-

cios o de servicios modificados”). Además, las normas incluyen dos aspectos
muy importantes: el sistema de gestión y la planificación e implementación de
la gestión del servicio.
En el ámbito de los servicios de TI, resulta esencial que los servicios se provean
en un marco de gestión eficaz y de calidad, para entender claramente los requisi-
tos y gestionar su cumplimiento. Las Normas ISO/IEC 20000 articulan el pro-
ceso de prestación de los servicios engranados sobre un sistema de gestión del
servicio (véase el capítulo 3). El proceso de mejora continua establecido por la
Norma ISO 9001 para la fabricación de productos o prestación de servicios
(siguiendo el ciclo PDCA: planificar, hacer, verificar y actuar – Plan, Do, Check,
Act), también se incorpora en esta norma como un “motor” de la mejora continua
de los servicios de TI (véase el capítulo 4).
La serie ISO 9000, normas de calidad

Según el diccionario de la Real Academia Española, la calidad se define como la “pro-
piedad o conjunto de propiedades inherentes a algo que permiten juzgar su valor”.
El aseguramiento de la calidad nace como una evolución natural del control de cali-
dad, que resultaba limitado y poco eficaz para prevenir la aparición de defectos.
Para ello, se hizo necesario crear sistemas de calidad que incorporasen la preven-
ción como forma de funcionamiento y gestión, y que, en todo caso, sirvieran para
anticiparse a los errores antes de que estos se produjeran.
Un sistema de gestión de la calidad se centra en garantizar que el producto o el
servicio ofrecido por una organización cumple con las especificaciones establecidas
previamente por la empresa y el cliente, y así, asegurar unos niveles de calidad pre-
decibles y su mejora continua a lo largo del tiempo.
El sistema de gestión de la calidad general es el conjunto de elementos interrelacio-
nados de una empresa u organización por los cuales se organiza y planifica el tra-
bajo de la misma en la búsqueda de la satisfacción de sus clientes. Sus elementos
principales son:
• La estructura de la organización.
• Sus procesos.
• Sus documentos.
• Sus recursos.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
ITIL (Information Technology Infrastructure Library)

Es un conjunto de publicaciones que recogen las buenas prácticas en la gestión de
servicios de las TI. Define un modelo de procesos bastante amplio que abarca
desde la definición de la estrategia hasta la gestión de las infraestructuras. El éxito y
la fama de ITIL se han fundamentado en la calidad de sus buenas prácticas y en la
flexibilidad para que las empresas pudieran adaptarlas a sus necesidades.
Entre 1989 y 1992, la versión 1 de ITIL se centraba en la gestión de la tecnología
y estaba claramente orientado al entorno mainframe. Paulatinamente, las prácticas
fueron evolucionando hacia procesos y servicios. ITIL, en su versión 2 (de princi-
pios del año 2000), se estructuraba en 7 libros básicos (además, hay uno nuevo de
dedicado al inventariado o a la gestión de activos software y otro enfocado a imple-
mentaciones en organizaciones de TI de menor escala como en pymes). En la
figura 1.6 se muestra la evolución histórica de ITIL y la aparición de ISO/IEC
20000 en los últimos años.
ISO/IEC UNE-ISO/ Evolución

BS 15000 20000 IEC 20000 ISO/IEC 20000
1986 1989 2000 2005 2007
IBM,s itSMF ITIL v1: ITIL v2: Creación ITIL v3:

ISMA 42 libros 7 libros itSMF España 5 libros
ITIL v0:
Service Level
Management
Figura 1.6. Historia de la evolución de la normativa de gestión del servicio de TI

ITIL v2 se ha utilizado como base para la creación de las Normas ISO/IEC 20000.
En la figura 1.7, se muestra una representación típica de ITIL v2. En ella se puede
apreciar el negocio a la izquierda del todo, en el extremo derecho se sitúa la tecno-
logía, y, en medio, haciendo que la tecnología sea útil para el negocio están los pro-
cesos ITIL. De ellos, los dos libros más valiosos por su contenido y más aceptados
por el mercado son los relativos a la gestión de servicio (libros Soporte de Servicio y
Provisión de Servicio publicados por OGC).
Planificación de la implantación de gestión del servicio
Perspectiva Gestión de servicio Gestión de

de negocio infraestructuras TIC
Soporte de servicio
• Gestión relación • Diseño y
con negocio • Centro atención usr. planificación
• Gestión relación • Incidente • Despliegue L
proveedores A
E • Problema • Operación
L • Planificación • Configuración • Soporte técnico T
y desarrollo • Financiero • Cambio E
N arquitectura TI • Continuidad • Entrega C
E • Relación • Disponibilidad N
G formación y
Gestión O
O comunicación • Capacidad
de activos L
C de TI con el • G. nivel de servicio O
I negocio
Provisión de servicio Gestión de G
O
la seguridad Í
A
Gestión de aplicaciones • Planificar
• Implementar
• Requerimientos
• Evaluar
• Diseñar y construir
• Mantener
• Despliegue
• Controlar
• Operar
• Optimizar
Fuente: Libro ITIL Soporte de Servicio publicado por OGC y e.p.
Figura 1.7. Procesos definidos en los libros ITIL v2

0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
La versión 3 de ITIL, que apareció a mediados de 2007, respeta los principales

procesos del soporte y de la provisión del servicio ya definidos en la versión ante-
rior. También saca a la luz mucha de las actividades de gestión de TI no reflejadas
anteriormente, ampliando su alcance a más de 20 procesos. Esta versión pone
mayor énfasis en la integración de TI con el negocio. Se estructura en torno al ciclo
completo de creación de servicios: estrategia, diseño, transición, operación y
mejora continua (véase la figura 1.8).
Diseño
del servicio
Estrategia
del servicio
del servicio
Operación
ITIL v3
ón
s ici icio
an rv
Tr l se
de
Mejora
del servicio
Fuente: Libro ITIL Estrategia del Servicio publicado por OGC y e.p.
Figura 1.8. La estructura de los libros ITIL v3 se articula

según el ciclo de vida de los servicios
El conjunto de temática y procesos tratados en ITIL v3 se muestra en la figura 1.9.
MEJORA
ESTRATEGIA DISEÑO TRANSICIÓN OPERACIÓN
CONTINUA
Estrategia del servicio Diseño del servicio Transición del servicio

• Generación de la estrategia • Diseño de servicios nuevos o • Planificación y soporte de la
• Gestión financiera de TI modificados transición
• Gestión de la demanda • Gestión del catálogo de servicios • Gestión de cambios
• Gestión del porfolio de servicios • Gestión de nivel de servicio • Gestión de la configuración y
• Gestión de la capacidad de activos del servicio
• Gestión de la disponibilidad • Gestión de versiones y
despliegues
• Gestión de la continuidad del
servicio TI • Validación y pruebas del servicio
• Gestión de la seguridad de la • Evaluación
información • Gestión del conocimiento
• Gestión de suministradores
Mejora continua del servicio Operación del servicio
• El proceso de mejora Procesos:
en 7 etapas • Gestión de eventos
• Informes del servicio • Gestión de incidencias
• Medición del servicio • Gestión de peticiones
• Retorno de inversión para la • Gestión de problemas
mejora
• Preguntas al negocio para
la mejora
ITIL v3 • Gestión de accesos
Funciones:
• Gestión de nivel de servicio • Centro de servicio al usuario
• Gestión técnica
• Gestión de operaciones TI
• Gestión de aplicaciones
Fuente: Libros ITIL v3 publicados por OGC y e.p.
Figura 1.9. Contenido de las cinco etapas del ciclo de vida

de los servicios en ITIL v3
Otras normas y metodologías relacionadas son: COBIT para la auditoría y

gobierno de TI, ISO/IEC 27001 para la seguridad, CMMI e ISO/IEC 15504
(SPICE) como modelos de madurez del desarrollo del software. En los apartados
siguientes se presenta una introducción a ellas.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
COBIT (Control objectives for information and related

technology)
Es un conjunto de mejores prácticas e indicadores para el control y auditoría de los
sistemas de información. Fue creado por ISACA (Information Systems Audit and
Control Association) y el ITGI (IT Governance Institute) y ha ido extendiendo su
alcance hacia las métricas de TI y las disciplinas de gobierno de las TI.
La primera edición fue publicada en 1996, la segunda en 1998, la tercera en 2000
y la cuarta en Diciembre de 2005.
COBIT 4 se estructura en cuatro dominios que cubren un total de 34 objetivos
principales de control (denominados también procesos), que permiten garantizar
un adecuado sistema de gobierno para el entorno de las TI. En la figura 1.10 se
muestran estos dominios.
Monitorizar y evaluar Planear y organizar
ME1 Monitorizar y evaluar el desempeño PO1 Definir el plan estratégico de TI

de TI PO2 Definir la arquitectura de la información
ME2 Monitorizar y evaluar el control interno PO3 Determinar la dirección tecnológica
ME3 Garantizar cumplimiento regulatorio PO4 Definir procesos, organización y
ME4 Proporcionar gobierno de TI relaciones de TI
PO5 Administrar la inversión en TI
PO6 Comunicar las aspiraciones y la
dirección de la gerencia
Entregar y dar soporte
ión En PO7 Administrar recursos humanos de TI
ac ca de treg
DS1 Definir y administrar niveles de servicio l ine tégi va a PO8 Administrar calidad
A ra lor
t
DS2 Administrar servicios de terceros es PO9 Evaluar y administrar riesgos de TI
de r tración
Med mpeño
DS3 Administrar desempeño y capacidad Gobierno PO10 Administrar proyectos

dese
os
DS4 Garantizar la continuidad del servicio de TI

ición
iesg
inis
DS5 Garantizar la seguridad de los sistemas

Adm
del
DS6 Identificar y asignar costos Adquirir e implantar

Administración
DS7 Educar y entrenar a los usuarios AI1 Identificar soluciones automatizadas
de recursos
DS8 Administrar la mesa de servicio y los AI2 Adquirir y mantener el software aplicativo
incidentes
AI3 Adquirir y mantener la infraestructura
DS9 Administrar la configuración tecnológica
DS10 Administrar los problemas AI4 Facilitar la operación y el uso
DS11 Administrar los datos AI5 Adquirir recursos de TI
DS12 Administrar el ambiente físico AI6 Administrar cambios
DS13 Administrar las operaciones AI7 Instalar y acreditar soluciones y cambios
Fuente: ISACA.
Figura 1.10. Los 4 dominios de COBIT para el gobierno de TI

En el ámbito de la certificación de los profesionales, en 2008 ISACA ha puesto en

marcha la certificación en el gobierno de las TI (CGEIT, Certified in the Governance
of Enterprise IT). Además, existe la acreditación a título profesional para auditor de
las TI (CISA, Certified Information Systems Auditor) y la relativa a la seguridad
de las TI (CISM, Certified Information Security Manager).
Vinculado a COBIT, y con el fin de desarrollar las prácticas para la medición de del
valor de la contribución de TI al negocio, ISACA ha creado el marco Val IT.
ISO/IEC 27001 e ISO/IEC 17799 para la seguridad

de las TI
El objetivo de la gestión de la seguridad de la información es asegurar la continui-
dad de las operaciones de la organización y reducir al mínimo los daños causados
por una contingencia, así como, optimizar la inversión en tecnologías de seguridad.
ISO/IEC 27001 establece los principios de: integridad, disponibilidad y continui-
dad de la información. Proporciona un modelo para la creación, implementación,
operación, supervisión, revisión, mantenimiento y mejora de un sistema de gestión
de la seguridad de la información (SGSI). Esta norma establece un conjunto de 30
actividades para la gestión de la seguridad, define 11 áreas principales de control,
para cada una establece 39 objetivos de control y 133 controles (o medidas de sal-
vaguarda) de seguridad. Las áreas de control son:
• Área: 5. Política de seguridad.
• Área: 6. Aspectos organizativos de la seguridad de la información.
• Área: 7. Gestión de activos.
• Área: 8. Seguridad ligada a los recursos humanos.
• Área: 9. Seguridad física y ambiental.
• Área: 10. Gestión de comunicaciones y operaciones.
• Área: 11. Control de acceso.
• Área: 12. Adquisición, desarrollo y mantenimiento de los sistemas de infor-
mación.
• Área: 13. Gestión de incidentes de seguridad de la información.
• Área: 14. Gestión de la continuidad del negocio.
• Área: 15. Cumplimiento.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
En la figura 1.11 se muestra la estructura de actividades propuesta en la norma.
Plan Ciclo PDCA Modelo en ISO/IEC 27001

Planificar
• Planificar 4.2.1 Creación del SGSI
Do Act
Hacer Actuar • Hacer 4.2.2 Implementación y operación del SGSI
• Verificar 4.2.3 Supervisión y revisión del SGSI
Check
Verificar • Actuar 4.2.4 Mantenimiento y mejora del SGSI
Figura 1.11. Estructura de actividades de ISO/IEC 27001
ISO/IEC 17799 (que pasará a ser denominada ISO/IEC 27002) recoge un código
de buenas prácticas para la gestión de la seguridad de la información. Se centra en
desarrollar los objetivos de control de la seguridad, y para cada uno de ellos, se
indica una guía para su implantación. Cada organización debe considerar cuántos
serán realmente los aplicables según sus propias necesidades.
CMMI (Capability Maturity Model Integration)

CMMI es una evolución de estándar inicial CMM, que fue desarrollado por el SEI
(Software Engineering Institute) de la universidad Carnegie Mellon, en 1986. Fue
iniciado en respuesta a la petición del Gobierno de los EEUU (Departamento de
Defensa, DoD) de proporcionar un método para controlar la capacidad de desarro-
llo de software de sus contratistas.
Originalmente, fue diseñado para su uso por los desarrolladores de software, pero
hoy se ha ampliado, proporcionando un modelo completo de evaluación de la
madurez de las actividades de desarrollo de aplicaciones de una organización. Este
modelo está estructurado y repleto de prácticas de gran utilidad para la mejora de
las actividades de una organización de TI.
En la figura 1.12 se muestra la estructura de las prácticas de CMMI en cuatro áreas
denominadas constelaciones. Cada una de estas constelaciones se pueden conside-
rar equivalentes a un libro de ITIL. En el modelo CMMI a los procesos se les deno-
mina área de proceso (PA, Process Area). Se establece una constelación común
(CMMI Fountation) que contiene los procesos que son comunes, una específica
CMMI
for Services
CMMI
Foundation
16 áreas
de proceso
CMMI for CMMI for
comunes
Development Acquisition
Figura 1.12. Constelaciones (áreas o libros) de CMMI
para el desarrollo de aplicaciones (CMMI for Development), otra para las adquisi-
ciones (CMMI for Adquisition) y una nueva para la prestación de servicios (CMMI
for Services).
CMMI describe cinco etapas evolutivas (niveles) en las cuales una organización se
sitúa según la madurez de sus procesos:
1. Inicial (Initial). Los procesos son caóticos; pocos procesos están realmente
definidos.
2. Repetible (Repeatable). Se establecen los procesos básicos y se observa cierto
nivel de disciplina respecto a ellos.
3. Definido (Defined). Todos los procesos están definidos, documentados, nor-
malizados e integrados.
4. Gestionado (Managed). Los procesos se miden recogiendo datos detallados
de los mismos.
5. En optimización (Optimizing). La mejora de los procesos es continua y pro-
porciona nuevas ideas y oportunidades.
Con la publicación en Marzo del 2009 de CMMI for Services, el SEI también entra
en el ámbito de la gestión del servicio, con bastante solape con ITIL e ISO/IEC
20000. En la figura 1.13 se muestran los procesos de este nuevo modelo.
0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
Las 24 áreas de proceso (PA) en CMMI-SVC
Support Service Establishment and Delivery

• Causal Analysis and Resolution (CAR) • Incident Resolution and Prevention (IRP)
• Configuration Management (CM) • Service Delivery (SD)
• Decision Analysis and Resolution (DAR) • Service System Development (SSD)
• Measurement and Analysis (MA) • Service System Transition (ST)
• Process and Product Quality Assurance (PPQA) • Strategic Service Management (STSM)
Process Management Project Management

• Organizational Innovation and Deployment (OID) • Capacity and Availability Management (CAM)
• Organizational Process Definition (OPD) • Integrated Project Management (IPM)
• Organizational Process Focus (OPF) • Project Monitoring and Control (PMC)
• Organizational Process Performance (OPP) • Project Planning (PP)
• Organizational Training (OT) • Requirements Management (REQM)
• Risk Management (RSKM)
• Quantitative Project Management (QPM)
• Service Continuity (SCON)
• Supplier Agreement Management (SAM)
Fuente: SEI.
Figura 1.13. Los procesos definidos en CMMI para servicios (CMMI-SVC)

en su versión 1.2
ISO/IEC 15504 (SPICE, Software Process Improvement

and Capability dEtermination)
En el ámbito del desarrollo del software en enero de 1993 en el seno del comité con-
junto de ISO e IEC, surge el proyecto SPICE para el desarrollo de un estándar
internacional para la evaluación de los procesos de construcción del software. El
resultado de este trabajo se plasmó en la serie de normas ISO/IEC 15504, que pre-
sentan un modelo de referencia que describe los procesos de una organización para
ejecutar, adquirir, desarrollar, operar, evolucionar y proporcionar soporte al soft-
ware. Este marco es la respuesta de la normativa internacional al modelo de madu-
rez CMMI for Development y en muchos aspectos se solapa.
La arquitectura del modelo organiza las prácticas en números de categorías utili-
zando diferentes tipos de aproximaciones. La arquitectura distingue entre:
• Prácticas base. Actividades esenciales de un proceso específico, agrupado

por categorías de procedimientos y procesos de acuerdo al tipo de actividad.
• Prácticas genéricas. Aplicables a cualquier proceso, que representa las
actividades necesarias para administrar el “proceso” y mejorar su potencia-
lidad.
El modelo agrupa a los procesos en cinco categorías:

• Procesos cliente-proveedor (customer-supplier). Esta categoría consta de los
procesos que directamente impactan al cliente, al soporte de desarrollo y a la
transición del software al cliente.
• Procesos de ingeniería (engineering). Esta categoría consta de los procesos
que directamente especifican, implementan, y mantienen un sistema, un pro-
ducto de software y la documentación del usuario.
• Procesos de proyecto (project). Esta categoría consta de los procesos esta-
blecidos dentro del proyecto, coordinación y administración de los recursos
para producir un producto o proveer un servicio para satisfacer al cliente.
• Procesos de soporte (support). Esta categoría consta de los procedimientos
que establecen y soportan el desempeño de los otros procesos del proyecto.
• Procesos de la organización (organization). Esta categoría consta de los
procesos que establecen las metas de negocio de la organización, los proce-
sos de desarrollo y los recursos que ayudan a la organización alcanzar dichas
metas.
En la figura 1.14 siguiente se muestra un esquema con estos procesos:
Procesos cliente-proveedor
Procesos de ingeniería
Procesos
Procesos de proyecto
de soporte
Procesos de organización
Fuente: SPICE.
Figura 1.14. Las cinco categorías de procesos definidas en SPICE

0
50
38
BIT
MI CO
CM
001
ITIL 27
00 00
90 200
Existen seis niveles de capacidad en el modelo:

• Nivel 0: Incompleto. Sería un fracaso general tratar de aplicar las prácticas
base a los procesos, ya que no es fácil identificar las salidas de los procesos o
el funcionamiento de los productos.
• Nivel 1: Realizado. Generalmente se ejecutan las prácticas base de los pro-
cesos. La ejecución de dichas prácticas puede no ser planificada rigurosa-
mente y ni seguida, y dependerá del conocimiento y esfuerzo personal. Se
identifican algunos procesos.
• Nivel 2: Gestionado. Se planifica y se sigue la ejecución de las prácticas
base en los procesos. El desempeño estará acorde con los procedimientos
especificados. La primera distinción entre el nivel 1 y el 2 es que la ejecución
de los procesos está planificada y administrada y progresan hacia un modelo
bien definido.
• Nivel 3: Establecido. Las prácticas bases se ejecutan de acuerdo a una ver-
sión adaptada del estándar. Los procesos están aprobados, bien definidos y
documentados.
• Nivel 4: Predecible. Se recaban y evalúan las mediciones detalladas del ren-
dimiento o ejecución. Se conoce de forma cuantitativa el rendimiento de los
procesos y es posible su predicción. Las prácticas se administran objetiva-
mente. La calidad de las mismas se conoce cuantitativamente.
• Nivel 5: Optimizado. Se establecen en forma cuantitativa procesos y metas
eficientes, basados en los objetivos de la organización. Los procesos se van
mejorando de forma continua, mediante la retroalimentación (feedback)
obtenida por los resultados de procesos definidos, por ideas, por pilotos y
por nuevas tecnologías.
2
Capítulo 2
Entender las
Normas ISO/IEC 20000
2.1. Introducción a las Normas ISO/IEC 20000

2.2. Objeto y campo de aplicación de ISO/IEC 20000
2.3. La estructura de las Normas ISO/IEC 20000
2.4. Relación entre ISO/IEC 20000 e ITIL
3. Sistema de Gestión del Servicio de TI (SGSTI)
4. Planificación e implementación de la gestión del servicio (PDCA)
5. Planificación e implementación de nuevos servicios o de servicios modificados
6. Procesos de la provisión del servicio

6.5 Gestión de la capacidad 6.1 Gestión de 6.6 Gestión de la seguridad
6.3 Gestión de la nivel de servicio de la información
continuidad y 6.2 Generación de 6.4 Elaboración de
disponibilidad informes del servicio presupuesto y contabilidad
del servicio de los servicios de TI
9. Procesos de control
10. Proceso 9.2 Gestión del cambio 7. Procesos
de entrega de relaciones
10.1 Proceso de gestión 8. Procesos 7.2 Gestión de las
de la entrega de resolución relaciones con el negocio
8.2 Gestión del incidente 7.3 Gestión de
8.3 Gestión del problema suministradores


Gestión del cambio
Proceso Procesos
2. Entender las Normas ISO/IEC 20000 53
2.1. Introducción a las Normas ISO/IEC 20000

La serie de Normas ISO/IEC 20000 (UNE-ISO/IEC 20000 en la versión espa-
ñola) es el primer conjunto de normativa internacional específica para la gestión de
los servicios basados en las Tecnologías de la Información (TI). Presentan una
organización cabal de las principales actividades necesarias para gestionar estos servi-
cios, agrupadas en un conjunto de procesos considerados esenciales para la creación,
prestación y evolución de los servicios de las TI. Al aplicar sus requisitos y reco-
mendaciones, las organizaciones de TI emprenderán un camino indudable de
mejora en el control y la calidad de su actividad. Es el primer gran salto hacia la
excelencia demandada por la sociedad a las TI.
Se pueden considerar como normas “troncales” en la gestión de las TI, pues estruc-
turan en torno a procesos las actividades más esenciales. Alrededor del eje vertebra-
dor que crean las Normas ISO/IEC 20000 se irán construyendo y transformando
el resto de las funciones de la organización de las TI. Sobre este núcleo central,
creado para la gestión de las TI, se irán incorporando otras mejores formas de hacer
proporcionadas por otras normas, otros marcos de mejores prácticas, por la expe-
riencia propia de la empresa o por las aportaciones de consultores externos.
Las Normas ISO/IEC 20000 introducen en la organización de las TI una forma de
trabajo metódica, integrada y orientada a los procesos, haciendo especial énfasis en
garantizar la calidad del servicio a los distintos clientes de las TI. Además, articulan
su implantación con un sistema de gestión específico, que incorpora la disciplina y
el rigor de ISO 90000 en la implantación del modelo de trabajo en las TI.
Las Normas ISO/IEC 20000 forman parte del conjunto de normas producidas por
la Organización Internacional de Normalización (ISO) y la Comisión Electrotéc-
nica Internacional (IEC). Su adopción como normas internacionales surge a raíz
de la iniciativa de elevar a ISO e IEC las normas británicas BS 15000 relativas a la
gestión del servicio de las TI. Las Normas ISO/IEC 20000 hoy vigentes se trami-
taron en ISO a través del procedimiento rápido denominado procedimiento fast-
track. Esto quiere decir, que estas normas tienen muchas similitudes con la origi-
nal, que la duración del proceso es de aproximadamente un año, y que ha contado
con la participación y voto de los representantes nacionales en ISO/IEC.
Las Normas ISO/IEC 20000 se componen de dos partes: la primera es la especifi-
cación para la gestión del servicio y tiene un carácter preceptivo, y la segunda se
establece como un código de buenas prácticas o recomendaciones. Ambas partes
forman un marco para definir las características de los procesos implicados en la
gestión del servicio, que son esenciales para la prestación de los mismos con la cali-
dad requerida.
Las Normas UNE-ISO/IEC 20000 son las traducciones al castellano de las ante-
riores ISO/IEC, están formadas por dos partes publicadas como documentos inde-
pendientes:
• UNE-ISO/IEC 20000-1:2007 Tecnología de la información. Gestión del
servicio. Parte 1: Especificaciones. Contiene los requisitos exigibles para cum-
plir con la norma. Por ello, el verbo de sus frases suele contener un “debe”,
indicando que el requisito tiene que ser satisfecho para ser acorde con la
norma.
• UNE-ISO/IEC 20000-2:2007 Tecnología de la información. Gestión del
servicio. Parte 2: Código de buenas prácticas. Esta parte contiene a veces una
extensión o detalle de los requisitos de la parte 1, mientras que en otras oca-
siones se desarrollan los requisitos con más profundidad. La parte 2, utiliza
el condicional “debería”, que se interpreta como una recomendación para
satisfacer el requisito de la parte 1, pero quizás no la única.
Dada la equivalencia entre estas normas ISO/IEC (en inglés) y las normas UNE
(en castellano), a partir de ahora en el libro se utilizará únicamente el término
ISO/IEC 20000 para ambas normas.
En la figura 2.1 se muestran los objetivos de cada una de las partes de estas normas
frente al alcance más amplio del presente libro.
Norma UNE-ISO/IEC 20000-1 Norma UNE-ISO/IEC 20000-2 Este libro

Especificaciones Código de buenas prácticas
+ ISO/IEC 20000-1
Requisitos de cumplimiento Detalle de los requisitos. + ISO/IEC 20000-2
obligatorio para certificarse Necesaria para concretar + ITIL
el alcance de los requisitos
+ Experiencia de los autores
de la parte 1
+ Directrices de implantación
“Debe” “Debería”
Figura 2.1. Las dos partes de las Normas ISO/IEC 20000 y su reflejo en
el presente libro
Conviene tener siempre presente que el objetivo de estas normas, y el sentido de su

aplicación, es mejorar los servicios prestados por las TI. Por ello, hay que entender que
ambas partes contribuyen a ello, y las dos deberán ser tenidas en cuenta en este
camino. Adicionalmente, para alcanzar un buen servicio de TI hacen falta bastantes
temas más, complementarios a las normas, relativos a: el liderazgo y la estrategia, a las
personas y su organización, al resto de actividad y de procesos que se deben realizar,

Gestión del cambio
Proceso Procesos
a la tecnología y su adecuado dominio, el cambio cultural, a la disposición de herra-

mientas, etc.
Si ambas partes deben tenerse en cuenta para la mejora del servicio, al abordar un
proceso de certificación, es cuando habrá que discernir entre los requisitos impres-
cindibles y obligatorios de estas normas y cuáles de ellos son opcionales. A este res-
pecto, los requisitos que se deben cumplir son los especificados en la parte 1 de la
norma, mientras que la parte 2, unas veces aclara o explica la parte primera, y otras
desarrolla una de las formas posibles de implantar dichos requisitos. También habrá
que determinar cuál es el criterio de alcance que se debe aplicar a un requisito en
el caso particular de una organización (por ejemplo, qué se exigirá para cumplir el
requisito de tener una base de datos de la configuración o CMDB). En el proceso
de implantación será el experto el que determine el alcance más adecuado a la orga-
nización. Durante el proceso de certificación será el auditor quién dará por válida o
no una evidencia de cumplimiento en función de su propio criterio y experiencia.
Diferencia entre norma y regulación

Una norma, según define la legislación española (Ley 21/1992), es “una especifica-
ción técnica de aplicación repetitiva o continuada, cuya observancia no es obligato-
ria, establecida con la participación de todas las partes interesadas, que aprueba un
organismo reconocido a nivel nacional o internacional”. Mientras que un regla-
mento técnico, se refiere a “una especificación técnica, relativa a productos, procesos
o instalaciones industriales, establecidas con carácter obligatorio a través de una dis-
posición de la Administración, para su fabricación, comercialización o utilización”.
Por tanto, la norma en sí misma constituye una recomendación y no es de obligado
cumplimiento por las organizaciones; su implantación y cumplimiento es volunta-
rio. La regulación o reglamentación pueden exigir el cumplimiento de los requisi-
tos definidos en una norma. Es en este caso cuando la norma pasa a ser de obligado
cumplimiento para las organizaciones afectadas. Hay que recalcar que en el caso de
las Normas ISO/IEC 20000, los requisitos que contienen son exigibles sólo al
efecto de certificar la conformidad de una organización con ellas de manera volun-
taria, no porque exista una ley o regulación lo exija.
ISO/IEC 20000 se centran en el ámbito de gestión de

los servicios de TI
Es importante posicionar adecuadamente las Normas ISO/IEC 20000 dentro de
todo el ámbito de la actividad de TI, pues estas normas se centran en un conjunto
esencial de la actividad de gestión de los servicios, pero no abarcan la totalidad de

la actividad de TI.
No son unas normas sobre la tecnología en sí misma, sino que se centran en las
actividades de las personas para gestionarlas (procesos) y en identificar los roles
necesarios para llevarlas a cabo. En la figura 2.2 se muestra que el ámbito de estas
normas es la gestión de las TI, por debajo del gobierno de las TI y por encima de
la gestión de equipos de trabajo, las herramientas (aunque influye en ellas y las uti-
liza) y las capas tecnológicas.
Fuente: Telefónica.
Figura 2.2. Las Normas ISO/IEC 20000 se centran en las

actividades de gestión de las TI

Gestión del cambio
Proceso Procesos
El hecho de que estas normas especifiquen los detalles de un total de 14 procesos

(estos 14 procesos señalados, son los recogidos en los apartados 5 a 10 de las nor-
mas), no significa que sean estos los únicos a tener en cuenta. Hay que verlos como
actividades fundamentales, pues la industria está en plena efervescencia definiendo
estándares y marcos de mejores prácticas en torno a la gestión de las TI.
Además de los procesos contemplados en la norma, hay otras disciplinas que hay
que tener en cuenta para lograr la excelencia del proveedor de TI, como son:
• La alineación de TI con las necesidades del negocio.
• La gestión de la demanda de las necesidades del negocio.
• La planificación de la cartera anual de proyectos.
• La madurez de los procesos de desarrollo y sus metodologías.
• El imprescindible conocimiento técnico.
• La arquitectura de las aplicaciones y de la infraestructura.
• La renovación de las infraestructuras.
• La calidad de los proveedores y de los servicios contratados.
• El liderazgo de la dirección, la motivación del personal, etc.
Si realizásemos un esquema que reflejara toda la actividad llevada a cabo en TI, las
funciones y los recursos tecnológicos, tendríamos:
• Para coronar el esquema, en la parte más alta, se definirían las actividades de
gobierno de TI: estrategia, alineación con el negocio, etc.
• Por debajo de ellas estarían los procesos de gestión del servicio de TI.
• En el siguiente nivel se situarían los equipos que constituyen las fuerzas de
trabajo de TI: con la operación, funciones técnicas, el desarrollo de software,
y el resto de especialidades y conocimientos tecnológicos
• A continuación, aparecería la capa de herramientas: de soporte a la gestión,
de administración técnica, de monitorización, etc., es decir, las herramientas
que hacen que la actividad sea más fluida y controlada.
• Por último la capa en la base del esquema, que alojaría la tecnología: siste-
mas, aplicaciones e infraestructura de TI (tecnología suministrada por los
fabricantes, comunicaciones, edificios para alojarlos, etc.)
En este esquema las normas se posicionarían sobre el área de la gestión del servicio,
debido a su carácter organizacional y de gestión. En la figura 2.3 se muestra el
esquema con todo su detalle.
Figura 2.3. En el mapa de disciplinas de TI, las Normas ISO/IEC 20000

contribuyen a la parte troncal de la gestión del servicio
Principios básicos de ISO/IEC 20000

Cuando ISO, IEC y las empresas del sector se plantearon la forma de organizar las
actividades en las áreas de TI se dieron cuenta que, además de la omnipresente tec-
nología, tenían que poner foco en cuatro principios tradicionalmente relegados
(véase la figura 2.4):
• El servicio. Es fundamental orientar las TI hacia el objetivo de prestar servicio
a sus áreas de negocio. La actividad de TI se debe estructurar completamente
bajo el concepto de servicio y no centrarse exclusivamente en el dominio de
tecnologías aisladas.

Gestión del cambio
Proceso Procesos
• La orientación al cliente. De forma complementaria a la anterior, los depar-

tamentos de TI tienen que desarrollar la capacidad de orientarse al cliente.
Cambiar las formas de trabajar para que los objetivos del negocio sean asu-
midos como propios. Se pone foco en las relaciones con el negocio y con los
usuarios de los servicios.
• La comunicación interna. Potenciar la comunicación interna entre las
diversas áreas y entre las personas.
• Los procesos internos. Organizar la actividad y el trabajo de todo el equipo
para que fluya sin fricciones y al ritmo demandado por el negocio. Todo ello,
dentro de un entorno de calidad y mejora continua.
• El servicio
• La orientación al cliente
ISO/IEC 20000
• La comunicación interna
• Los procesos internos
Proveedor del servicio TI

u organización TI
Figura 2.4. ISO/IEC 20000 introduce en TI cuatro principios
La importancia de los procesos en la provisión de

servicios de TI
En muchas disciplinas de la sociedad, para conseguir que un conjunto de activida-
des complejas engranen a la perfección, se ha desarrollado el enfoque basado en
procesos. Conocer brevemente el concepto de proceso nos ayudará a entender la
forma de actuar para mejorar la organización de TI. Tanto las Normas ISO/IEC
20000, como ITIL y otros marcos de referencia estructuran la actividad de TI
entorno a los procesos que cada uno de ellos considera esenciales.
En términos generales, un proceso se define como “conjunto de actividades mutua-
mente relacionadas o que interactúan, las cuales transforman elementos de entrada
en resultados” (UNE-EN ISO 9000). También se entiende como una serie de activi-
dades con valor añadido, acciones o tomas de decisión interrelacionadas, orientadas
a obtener un resultado específico. Todo proceso debe poder representarse mediante

un diagrama de flujo y poder medirse su rendimiento.
Al hablar de procesos nos estamos refiriendo a las diferentes etapas que contribu-
yen, de una manera ordenada, a la consecución de un objetivo definido. Por ejem-
plo, un proceso de fabricación está constituido por las fases consecutivas necesarias
para la elaboración de un producto. La disciplina de los procesos se lleva aplicando
desde hace años en las organizaciones que pretenden que un conjunto de personas
trabaje en equipo; sincronizadas, de una forma repetible y con eficiencia.
La Norma UNE-EN ISO 9001 también propone en su introducción un “enfoque
basado en procesos” para la mejora de la calidad, que se traduce en la aplicación de
un modelo de procesos dentro de la organización. Así, para que una organización
funcione de manera eficaz, tiene que identificar y gestionar numerosas actividades
relacionadas entre sí. Indica que: “una actividad que utiliza recursos y que se ges-
tiona con el fin de permitir que los elementos de entrada se transformen en resulta-
dos, se puede considerar como un proceso”. Frecuentemente, el resultado de un
proceso constituye directamente el elemento de entrada del siguiente proceso. En
la figura 2.5 se presenta un esquema de ejemplo de un proceso.
Actividades (de valor añadido)
Entradas Actividad Actividad Actividad Salidas

Tarea 1
Tarea 2 SUBPROCESO
Tarea n Actividad Actividad Actividad
Tarea 1
Tarea 2
Control Mecanismos
(actividades de evaluación)
Indicadores Recursos
y KPI
Roles
Propietario Objetivos
Herramientas
del proceso del proceso
Figura 2.5. Elementos principales que componen un proceso


Gestión del cambio
Proceso Procesos
Según indica la Norma UNE-EN ISO 9001, una ventaja del enfoque basado en
procesos es el control continuo que proporciona sobre los vínculos entre los proce-
sos individuales dentro del sistema de procesos, así como sobre su combinación e
interacción. Un enfoque de este tipo, cuando se utiliza dentro de un sistema de ges-
tión de la calidad, enfatiza la importancia de:
a) La comprensión y el cumplimiento de los requisitos.
b) La necesidad de considerar los procesos en términos que aporten valor.
c) La obtención de resultados del desempeño y eficacia del proceso.
d) La mejora continua de los procesos con base en mediciones objetivas.
Introduciendo los procesos en la forma de trabajar, no sólo se mejorará el servicio

prestado, sino que además, se incrementará la satisfacción del equipo al realizar un
trabajo más eficaz y organizado.
Normalmente, un proceso está formado por unas entradas, unas actividades y unos
resultados o salidas. Las actividades están formadas por tareas y controladas
mediante indicadores, que se corresponderán a los objetivos definidos del proceso y
será el rol del propietario del proceso quien asuma las responsabilidades del control.
De forma complementaria, existen unos mecanismos que posibilitan que las activi-
dades se realicen (recursos, roles participantes y herramientas necesarias). Por otra
parte, las actividades pueden agruparse en una serie de subprocesos, para hacer más
entendible el proceso principal. Un proceso puede necesitar instrumentos, herra-
mientas, formularios o mecanismos para llevarse a cabo, así como, una descripción
detallada de cada actividad (procedimientos e instrucciones de trabajo).
En el mundo de los procesos, y por lo tanto en ISO/IEC 20000, es muy impor-
tante tener presente los principios básicos que se deben respetar en la definición y
ejecución de un proceso para que éste sea efectivo:
• Un proceso tiene clientes (internos o externos).
• Un proceso tiene un objetivo comprometido.
• Un proceso tiene un responsable único.
• Sus actividades cruzan fronteras entre las diferentes unidades de la organi-
zación.
• Un proceso utiliza recursos, su actividad la realizan unos roles y suelen
requerir herramientas que los soporten.
Las Normas ISO/IEC 20000 definen una capa de procesos de TI que aglutina las
principales actividades para que los servicios se provean y presten según las exigencias
del negocio. Esta capa de procesos se utiliza por la organización tradicional de TI,
garantizado que estas actividades esenciales se ejecuten de la forma definida. Para
facilitar el trabajo es necesario implantar un conjunto de herramientas de soporte a
la ejecución de los procesos (capa de herramientas). Por tanto, la implantación de
las normas no requiere necesariamente cambiar la estructura organizativa. Aunque
sí será necesaria la definición detallada de los procesos y de los roles o funciones
específicos, que garanticen que son efectivos. En la figura 2.6 se representan la capa
de procesos ISO/IEC 20000 y la capa de herramientas como instrumentos al servi-
cio de la organización de TI y de sus equipos de trabajo.
Figura 2.6. Las Normas ISO/IEC 20000 definen las actividades

principales (procesos) a realizar por la organización de TI (equipos de trabajo)
Implantando y haciendo eficientes estos procesos básicos se conseguirá una mejor

organización de la sobrecargada actividad de las áreas de soporte y una mejora en
la calidad de los servicios prestados.
En las grandes organizaciones, su implantación suele llevar implícitamente asociada
la creación de una organización matricial en TI, la estructura jerárquica se ve cruzada
por los flujos de los procesos ISO/IEC 20000, que dependen del gerente, gestor o

Gestión del cambio
Proceso Procesos
responsable de cada proceso. En la figura 2.7 se aprecia un esquema típico de una

organización matricial, en columnas se representan las funciones, los departamentos
o unidades jerárquicas de la empresa, mientras que horizontalmente cruzan a estos
los procesos.
CIO
F1 F2 F3
P1
P2
P3
F: funciones o departamentos
P: procesos
Fuente: Gartner.
Figura 2.7. La implantación de procesos implica una organización matricial
Estas organizaciones matriciales generadas al implantar los procesos, se inician con

un fuerte peso y dominancia de las funciones verticales, para ir evolucionando
según maduran a dar más importancia a los procesos, que en su estado final de evo-
lución acaban dominando la organización. De hecho, en ITIL v3, los cinco libros
que lo estructuran invitan a transformar las funciones o departamentos tradiciona-
les en las cinco etapas del ciclo de vida del servicio (estrategia, diseño, transición,
operación y mejora continua), al que habría que añadir la construcción (apenas tra-
tada en ITIL v3).
Procedimientos e instrucciones de trabajo

Una vez definido el proceso, puede ser necesario realizar uno o varios procedimien-
tos que permitan su aplicación en la organización. Un procedimiento es el detalle
de cómo aplicar una parte de un proceso. Desarrolla las actividades y tareas que for-
man un proceso, e incluye una descripción detallada de cada una de ellas.
Un proceso describe “qué hay que hacer” y un procedimiento “cómo hay que
hacerlo” en una situación concreta. Por ejemplo, un proceso puede establecer que
hay que registrar el incidente en la herramienta de gestión de incidentes, y el proce-
dimiento indicar los pasos a dar en la herramienta concreta de gestión de inciden-
tes, qué hay que poner en cada campo, etc.
La mayor parte de las organizaciones suele completar sus procedimientos con ins-
trucciones de trabajo complementarias, más detalladas que los procedimientos,
cuyo objetivo es describir, hasta los últimos detalles necesarios, las tareas descritas
en los procedimientos. Una instrucción de trabajo puede elaborarse en el caso de
que haga falta más detalle en un procedimiento, por ejemplo, cuando roles distin-
tos tienen instrucciones de trabajo distintas dentro del mismo procedimiento.
Por tanto, procesos, procedimientos e instrucciones de trabajo tienen como finali-
dad primordial ser utilizadas por el personal en la realización diaria de su trabajo.
En el caso concreto de los procesos de gestión de TI, todos los procesos se deben
formalizar, pero la experiencia demuestra que no en todos ellos es productivo bajar
al nivel de detalle de procedimiento o de instrucción de trabajo. En general, será
útil poner énfasis en detallar aquellos procesos en los que:
• Se ve involucrado mucho personal.
• Se deben engranar un conjunto de actividades, subprocesos y tareas com-
plejos.
• Es necesaria una automatización minuciosa.
Típicamente, los procesos que tienen un flujo extenso, y que convendrá detallar,
son: la gestión del incidente (y la gestión de la petición del usuario), la gestión del
cambio, la gestión de la entrega y la gestión de suministradores. Más allá del
alcance de estas normas, será necesario bajar a nivel del procedimiento en: la ope-
ración, la gestión del evento o la gestión del acceso. En el resto de procesos, para la
mayoría de las organizaciones, detallarlos no aportará un valor adicional.

Gestión del cambio
Proceso Procesos
2.2. Objeto y campo de aplicación de

ISO/IEC 20000
ISO/IEC 20000-1 establece su objeto y campo de aplicación como:
UNE-ISO/IEC 20000-1
Esta parte de la Norma ISO/IEC 20000 define los requisitos para que un proveedor
del servicio proporcione servicios gestionados de una aceptable calidad a sus clientes.
Puede ser usada:
a) para negocios que solicitan ofertas para sus servicios;
Nota 1: El término “negocio” en esta norma internacional debería interpretarse en un sentido
amplio, abarcando aquellas actividades que son esenciales para alcanzar los fines que
persigue la organización.
b) para negocios que requieren de un enfoque consistente por parte de todos sus
proveedores del servicio en la cadena de suministro;
c) por proveedores del servicio para medir y comparar su gestión del servicio
de TI;
d) como base de una evaluación independiente;
e) por una organización que necesite demostrar su capacidad para proveer
servicios que cumplan con los requisitos de los clientes; y
f) por una organización que busque mejorar los servicios, mediante la aplica-
ción efectiva de los procesos para monitorizar y mejorar la calidad de los
servicios.
En relación a la estructura y tamaño del proveedor de TI, debemos indicar que los
requisitos de la norma son totalmente independientes de la estructura de la organi-
zación o tamaño de la misma. Aunque, cuanto mayor sea el tamaño del proveedor
o la complejidad de los servicios, mayores beneficios se podrán obtener de la apli-
cación de la norma. Un proveedor de servicio debe utilizar la organización que le
sea más apropiada, según su negocio, su cultura y su estrategia.
Para entender claramente el alcance de estas normas se debe comprender el signifi-
cado que se otorga a dos conceptos: “servicio de TI” y “proveedor de TI”.
Comprender el concepto de “servicio de TI”

Servicio, del latín servitium, se define en el diccionario de la Real Academia Espa-
ñola como la: “organización y personal destinados a cuidar intereses o satisfacer
necesidades del público o de alguna entidad oficial o privada, como; servicio de
correos, de incendios, de reparaciones, etc.”.
En ITIL v3, un servicio se define como “un medio de entregar valor a los clientes faci-
litando los resultados que los clientes quieren lograr sin la necesidad de que tengan la
propiedad de los activos necesarios, ni la responsabilidad de los riesgos asociados”.
El término servicio ya se da por conocido en estas normas y, por tanto, no se define
en ellas, pero para las áreas de TI internas de las empresas no les es fácil encajarlo
en su actividad. Resulta importante profundizar sobre su alcance para poder enten-
der el ámbito de aplicación de estas normas, ya que se centran en establecer los
requisitos necesarios para prestar estos servicios. Con frecuencia se contamina el
concepto de servicio que el negocio o cliente quiere recibir de TI, con los compo-
nentes tecnológicos que lo soportan. En cambio, cuando los servicios se ofrecen al
exterior, es el propio mercado y la competencia los que van perfilando su alcance y
correcta definición. Así, podríamos definir servicio como toda contraprestación por
la que el cliente paga. Pero en el caso de prestación de servicios internos, su alcance
no está tan claro y hay que hacer un cierto esfuerzo por conceptualizarlo.
En el ámbito interno de TI se podría definir servicio como “una funcionalidad
necesaria para los usuarios”, semejante al concepto utilizado en las relaciones
comerciales del mercado. Se entiende que un servicio de TI es una solución infor-
mática completa que cubre unas necesidades específicas del negocio, que TI entrega
y mantiene de forma autocontenida y empaquetada, liberando al cliente y a los
usuarios de las complejidades internas de su tecnología. De esta forma, los servicios
de TI se deben convertir en una parte esencial en la cadena de valor del negocio.
La distinción entre lo que es un servicio de TI y lo que no lo es depende de la agru-
pación conceptual que se quiera hacer. Normalmente se sigue el criterio de conside-
rar servicio aquello que claramente el cliente lo percibe como una unidad auto-conte-
nida y le aporta un cierto valor o utilidad. Pero aún así, la diferenciación es subjetiva.
En unos casos, el servicio está directamente vinculado a una aplicación (como la apli-
cación de facturación ligada al servicio de facturación). En otros, un servicio puede
utilizar varias aplicaciones (el de atención comercial se puede componer de las aplica-
ciones de: atención al cliente, ficha de cliente, registro de llamadas, etc.).
Ejemplos de servicios bajo el alcance de estas normas son lo los siguientes:
• La provisión del puesto de trabajo: el ordenador del puesto de trabajo conec-
tado, operativo y soportado.

Gestión del cambio
Proceso Procesos
• El correo electrónico.
• El sitio web de la empresa.
• El portal web interno de la empresa (la intranet).
• El servicio de ERP (Enterprise Resource Planning) de una empresa.
• El servicio de alojamiento de aplicaciones o portales web.
• El servicio de alojamiento de servidores ofrecido por un Internet Center.
• El servicio de facturación.
• El servicio de gestión del conocimiento.
• El servicio de colaboración.
En la figura 2.8 se muestra la visión de TI como un proveedor de servicios al ne-

gocio.
Servicios de TI
Negocio
Gestión Acceso en
de clientes teletrabajo
Gestión Provisión y
de ventas soporte del
Gestión de Correo
Gestión de puesto de trabajo
facturación electrónico
actuaciones
Figura 2.8. El concepto de TI como proveedor de servicios al negocio
En el fondo, la estructuración en servicios depende mucho de cada organización.

Estos se agrupan y explican en un catálogo de servicios de TI.
Además, el conocimiento de la definición de servicio es importante para compren-
der el alcance de las Normas ISO/IEC 20000, que están claramente orientadas a
mejorar los “servicios operativos” de TI, es decir, a aquellos que deben estar funcio-
nando regularmente. Normalmente un servicio se construye sobre equipamiento
informático (hardware), un software base, aplicaciones, comunicaciones, y requiere
una arquitectura, un soporte técnico y gestión para que se mantenga activo.
De forma clara, estas normas se refieren a los servicios que se prestan utilizando
como base los sistemas informáticos. Esta concepción de servicio no quiere decir
que no se puedan aplicar las directrices y recomendaciones a otro tipo, pero su apli-
cación habrá que matizarla e interpretarla, como es el caso de los servicios de las
operadoras de telecomunicaciones. Pero hay otros casos que no están en el alcance,
aunque también se denominan servicios, como por ejemplo: la prestación de servi-
cios de consultoría, la venta de equipamiento informático, etc. En la figura 2.9 se
muestra la simbología utilizada en el libro para estos dos omnipresentes conceptos.
Servicio de TI Proveedor de TI
Figura 2.9. Simbología utilizada en el libro

para representar el servicio de TI y el proveedor de TI
Por otra parte, es importante tener en cuenta el punto en el que se esté situado en
la cadena de provisión para determinar si tal o cual actividad es un servicio ofre-
cido, o bien, es un servicio contratado. Un área interna de una empresa ofrece ser-
vicios a los usuarios de la misma, pero a su vez, contrata servicios al mercado (el
centro de tele-atención, el alojamiento de sus equipos en un centro de proceso de
datos de un tercero, los servicios de telecomunicaciones, etc.). Así, en la posición
del área interna de TI, ésta ofrece servicios a sus usuarios y clientes, y contrata otros
servicios a los proveedores externos o internos.
Bajo la perspectiva de estas normas, el término servicio se utiliza para referirse al
prestado por la organización a la que se aplica la norma.
El concepto de “proveedor del servicio de TI”

El término “proveedor del servicio de TI” está omnipresente en las normas, es la
organización a la que se aplican las normas y para la que se establecen las directri-
ces y recomendaciones. Se utiliza para referirse a: el área, la empresa, el departa-
mento o la organización que presta el servicio de tecnologías de la información y
comunicaciones; y tiene clientes o áreas de negocio que contratan o solicitan los
servicios y usuarios de los utilizan.

Gestión del cambio
Proceso Procesos
En este ámbito, el término “proveedor del servicio de TI” se puede aplicar a cual-
quier unidad, departamento, organización o empresa que preste servicios de TI,
con independencia de que haya o no transacción económica, o del tamaño de la
organización. Algunos ejemplos de proveedor de TI pueden ser:
• Los departamentos de sistemas de información o departamentos de infor-
mática internos de las empresas.
• Empresas que ofrezcan servicios de TI al mercado.
A partir de este punto, a lo largo del libro se utilizará el término “proveedor de TI”
como sinónimo de organización de TI o departamento informático, dotándole del
mismo alcance que en las normas.
El papel del proveedor de TI aparece levemente descrito en las generalidades del
apartado 7.1 de la norma, cuando tratan las relaciones con el negocio.
UNE-ISO/IEC 20000-2
Esta norma se dirige hacia el rol de un proporcionan bienes o servicios a dicho

proveedor del servicio, el cual cumple proveedor del servicio, y los clientes, que
un papel entre los suministradores, que reciben los servicios.
La figura 2.10 muestra una representación simplificada de la posición de la organiza-

ción o proveedor de servicios de TI entre el suministrador y el negocio. También se
aprecia la diferencia entre los clientes de TI y los clientes del negocio en el mercado.
Servicio de TI
Cliente del
Cliente de TI negocio
Grandes
clientes
Relación Relación Pymes Consumo

Suministrador Proveedor de TI Negocio
(organización TI)
Figura 2.10. La organización o proveedor de TI presta servicios de TI al negocio

Conviene destacar que, para evitar la confusión terminológica, en las Normas

ISO/IEC20000 se ha adoptado el término de suministrador para designar a toda
organización a la que se le contrata algún tipo de prestación, quedando el término
proveedor para aquellas organizaciones o departamentos de TI que quiere cumplir
con lo especificado por la norma (a efectos de certificación). Se distingue, así, entre
suministrador de TI y proveedor de TI (área o departamento de TI). Esta conside-
ración es muy importante en el ámbito de estas normas, y hay que afinar el len-
guaje, utilizando siempre suministrador para estas prestaciones contratadas exter-
namente.
A partir de ahora en este libro, al igual que en las Normas ISO/IEC 20000, a la
organización de TI, bien sea departamento interno o unidad que presta servicios
externos al mercado, va a ser denominada como “proveedor de TI”. Concepto
que comprende tanto a las áreas o departamentos informáticos internos de las
empresas, como a cualquier tipo de servicio de tecnologías de la información
proporcionado.
2.3. La estructura de las Normas ISO/IEC 20000

Las actividades que se realizan para la prestación de un servicio de TI son múlti-
ples. La industria ya ha iniciado el camino para la definición de las más relevantes,
aquéllas que hay que definir y optimizar para que la organización de TI vaya mejo-
rando su funcionamiento. Las principales, consideradas más esenciales para el ser-
vicio, se definen tanto en estas normas, cómo en otros marcos de referencia. Algu-
nos de estos procesos esenciales ayudan a:
• Resolver de forma rápida los incidentes ocurridos en el servicio.
• Ir mejorando paulatinamente las taras ocultas en las tecnologías (hardware y
software) que soportan los servicios.
• Conocer con precisión la configuración de los servicios y sus componentes.
• Realizar cambios de una forma segura y eficiente.
• Entender con claridad las necesidades del cliente, establecer acuerdos preci-
sos con él y organizarse para ser capaces de cumplirlos.
• Identificar y controlar los costes para optimizar la eficiencia de la organización.
• Mejorar el tiempo de provisión de servicios nuevos.
• Garantizar la robustez de los servicios críticos para el negocio.
• Controlar el desempeño de los suministradores contratados.

Gestión del cambio
Proceso Procesos
Parece que los autores de ISO/IEC 20000 e ITIL (v2 y v3) suelen coincidir en
cuáles son los procesos básicos para la gestión de las TI. Así, estos diferentes
marcos de referencia tienen un núcleo con procesos bastante similares (inci-
dente, problema, configuración, cambio, entrega, nivel de servicio, disponibili-
dad, continuidad, capacidad y financiero). En cambio, a la hora de realizar la
agrupación conceptual de estos procesos, es donde los autores han dejado volar
su creatividad, proponiendo en sus modelos agrupaciones dispares. Por suerte,
estas diferentes agrupaciones son conceptuales y no tienen reflejo en el conte-
nido de los procesos que se han de aplicar. En el caso de las Normas ISO/IEC
20000, la agrupación tiene su lógica y es razonable (agrupaciones: provisión del
servicio, control, entrega, resolución y relaciones), pero distinta a lo establecido
en ITIL v2 (libros: soporte de servicio, provisión de servicio, gestión infraes-
tructuras, etc.) y distinto ITIL v3 (libros: estrategia, diseño, transición, opera-
ción y mejora continua). Así, se agrupan bajo la provisión de servicio procesos
distintos a los contemplados en ITIL v2 en su libro de provisión de servicio. En
ITIL v3 la agrupación se hace en función del ciclo de vida del servicio. Con
independencia de la agrupación de procesos que se realice, individualmente hay
un núcleo común (gestión del incidente, gestión del problema, gestión de la
configuración, etc.).
Los primeros apartados en estas normas están centrados en inculcar en TI las ense-
ñanzas aprendidas implantando y mejorando sistemas de gestión en todo tipo de
organizaciones. Por ello, los capítulos 3 y 4 se centran en: el sistema de gestión TI
y en la planificación e implementación de la gestión del servicio.
Prácticamente, el resto de estas normas se dedica a la definición de los procesos,
agrupados en: Planificación e implementación de servicios, nuevos o modificados;
Procesos de provisión de servicio; Procesos de relación; Procesos de resolución;
Procesos de control y Proceso de entrega.
En el esquema de la figura 2.11 se muestra el modelo básico utilizado en este
libro y en las normas para representar todo el alcance de la gestión del servicio de
TI. En el rectángulo exterior se sitúa el sistema de gestión del servicio de TI (que
se explica en el capítulo 3). Hacia el interior del rectángulo aparece de forma
inmediata las actividades de implantación del sistema de gestión (tratadas en el
capítulo 4). Una vez establecido el sistema que gestionará el servicio, su implan-
tación y mejora, se incorporan los 14 procesos establecidos en ISO/IEC 20000
(tratados en los capítulos de 5 al 10). Esta figura se utilizará de índice gráfico en
todo el libro.
Las Normas ISO/IEC 20000 se componen de un conjunto de procesos que inter-
actúan entre sí y que son necesarios para la prestación de un servicio con el obje-
tivo de normalizar la gestión de los sistemas de información mediante procesos
Capítulo 3 3. Sistema de Gestión del Servicio de TI (SGSTI)
Capítulo 4 4. Planificación e implementación de la gestión del servicio (PDCA)
Capítulo 5 5. Planificación e implementación de nuevos servicios o de servicios modificados
Capítulo 6 6. Procesos de la provisión del servicio

Capítulo 9 9. Procesos de control
Capítulo 10 Capítulo 8 Capítulo 7

Figura 2.11. Estructura de los procesos en las Normas ISO/IEC 20000

y los capítulos del libro
eficaces que articulen todas las actividades de la organización de TI hacia un claro

enfoque al servicio y al cliente. Las normas están divididas en las siguientes áreas:
El sistema de gestión de TI. Cuyo objetivo es proveer una gestión de TI que
incluya políticas y un marco de trabajo para hacer posible una efectiva gestión e
implementación de todos los servicios de TI. Estas normas siguen la estructura y
filosofía establecida por las normas ISO para la gestión con calidad de las organiza-
ciones, de la que ISO 9001 es la piedra angular. Para conseguir la transformación
de la actividad en TI, ISO/IEC 20000 establece que la gestión de TI se organice y
regule alineada con el modelo de gestión del resto de la empresa. Define un modelo
o sistema de gestión de TI que se integra sin fisuras en el mismo sistema de gestión
de calidad según el modelo ISO 9001 de la empresa.
Planificación e implementación de la gestión del servicio. Apartado destinado a

definir el proceso de implantación de estas normas, es decir, de la propia gestión

Gestión del cambio
Proceso Procesos
del servicio de TI (procesos, roles, relaciones, recursos, herramientas, cambio cul-

tural, etc.). También incorpora el ciclo de mejora continua, basado en el modelo
PDCA, internacionalmente reconocido y aceptado por ser, entre otros, el modelo
de gestión aplicado para calidad y para la gestión ambiental. La metodología cono-
cida como PDCA puede describirse brevemente como:
• P – Planificar: establecer los objetivos y procesos necesarios para conseguir
resultados de acuerdo con los requisitos del cliente y las políticas de la orga-
nización.
• D – Hacer: implementar los procesos.
• C – Verificar: realizar el seguimiento y la medición de los procesos y los pro-
ductos respecto a las políticas, los objetivos y los requisitos para el producto,
e informar sobre los resultados.
• A – Actuar: tomar acciones para mejorar continuamente el desempeño de
los procesos. Sirve de entrada a planificar.
En las normas, para cada fase del ciclo PDCA se establecen los requisitos y reco-
mendaciones a seguir por todo proveedor de TI.
Planificación e implementación de nuevos servicios o de servicios modifica-

dos. Describe el proceso de creación de un servicio nuevo o de realizar modifica-
ciones a los servicios existentes, para que se puedan gestionar y entregar con los
costes, calidad y plazos acordados con los clientes.
Procesos de provisión de servicio. Regulan las actividades necesarias para que los
servicios cumplan los cometidos pactados con el negocio. Cobran especial relevan-
cia frente a la necesidad de prestar servicios de TI de calidad, alineados a los objeti-
vos del negocio, que cubran las necesidades actuales y que deben ser capaces de
evolucionar rápidamente para cubrir las necesidades futuras. En estas normas, la
provisión de servicio aglutina 6 procesos:
• Proceso de gestión de nivel de servicio.
• Proceso de generación de informes del servicio.
• Proceso de gestión de la continuidad y disponibilidad del servicio.
• Proceso de elaboración de presupuesto y contabilidad de los servicios de TI.
• Proceso de gestión de la capacidad.
• Proceso de gestión de seguridad de la información.
Procesos de relaciones. Especifican las actividades de TI con su mundo exterior. Se

centran en dos apartados clave: por un lado establece y mantiene una buena relación
entre el proveedor del servicio y el cliente, comprendiendo la realidad del cliente
y los fundamentos de su negocio; por otro lado, haciendo foco en la gestión de los
suministradores o proveedores, para garantizar la provisión sin interrupciones de
los servicios de TI con calidad. Los procesos de relaciones en estas normas son:
• Proceso de gestión de relaciones con el negocio, que especifica las activida-
des para llevar a cabo el diálogo entre el proveedor de TI y sus clientes.
• Proceso de gestión de suministradores, define las actividades a tener en
cuenta en la gestión de los suministradores del proveedor de TI.
Procesos de resolución. Se centran en la resolución de incidentes nuevos o reinci-

dentes ocurridos sobre los servicios, que dificultan o impiden que estos cumplan su
cometido. Por un lado, trata de restaurar el servicio para cumplir el nivel de servi-
cio acordado con el negocio y los clientes tan pronto como sea posible o resolver
las peticiones de servicio. Por otro lado intenta minimizar los efectos negativos de
las interrupciones de servicio efectuando actividades tendentes a analizar la causa
de los incidentes y la gestión de los problemas, para lograr su cierre definitivo. Los
procesos de resolución en estas normas son:
• Proceso de gestión del incidente, entendiendo como tal la degradación par-
cial o total del servicio.
• Proceso de gestión del problema, centrado en la resolución definitiva de
defectos que causan incidentes repetidamente.
Procesos de control. Aseguran a los gestores la calidad de la información sobre

los servicios, así como, que todo cambio se realiza de una forma controlada. Con-
templan dos apartados clave: por un lado el control de todos los componentes del
servicio y la infraestructura, manteniendo la información precisa sobre la configu-
ración de dichos componentes, y por otro lado, asegurando que todos los cambios
que se produzcan sobre dichos componentes sean valorados, aprobados, implanta-
dos y revisados de una manera controlada. Los procesos de control en estas nor-
mas son:
• Proceso de gestión de la configuración, que mantiene al día la información
definida como esencial del proveedor de TI, los servicios y sus componentes.
• Proceso de gestión del cambio, que garantiza que todo cambio que se deba
realizar sigue las reglas marcadas. Aprueba y controla todos los cambios que se
producen en los servicios. Es muy importante no confundirlo con otro con-
cepto muy distinto que es la “gestión del cambio cultural” en la organización.

Gestión del cambio
Proceso Procesos
Proceso de entrega. Se centra definir las actividades a realizar durante la etapa de

tránsito de los cambios, desde la etapa de desarrollo hasta su paso a producción.
Asegura que todos los componentes necesarios para la puesta en producción real
de un servicio están correctamente definidos y probados, proporcionando al pro-
ceso de gestión del cambio la información necesaria para la aprobación, o no, de
la implantación de un servicio en producción real. Está formado por un único
proceso:
• Proceso de gestión de la entrega. Una vez aprobado el cambio, gestiona la
implantación, distribución y el seguimiento de uno o más cambios a realizar
en el entorno de producción real.
2.4. Relación entre ISO/IEC 20000 e ITIL

Las empresas y organizaciones, en general, agradecerán que los creadores de estas
normas intentaran respetar y asemejarse a otro marco o modelo extendido en el
mercado, como es ITIL. Esto permitiría a las organizaciones, con procesos ITIL ya
implantados, tener un buen camino recorrido para cumplir con ellas. No obstante,
hay diferencias entre ambos mundos: unas veces son evidentes ya desde el mismo
nombre del proceso, pero otras, son más sutiles y difíciles de detectar en una pri-
mera lectura. Este libro trata de exponer con claridad estas diferencias, tanto en el
resumen realizado en este apartado, como en la descripción detallada de los proce-
sos. La similitud con ITIL, permite aprovechar las buenas prácticas de éste para
tomarlas como una forma, aunque no la única, de cumplir los requisitos de
ISO/IEC 20000.
Estos dos marcos tienen mucho en común. Ambos cubren la gestión del servicio
de TI, se utilizan internacionalmente y cuentan con una oferta de formación
reglada por instituciones sectoriales.
A pesar del acoplamiento que existe entre ISO/IEC 20000 e ITIL, no se alinean
completamente. Esto es en parte debido a la diferencia fundamental existente entre
una norma y un marco de mejores prácticas.
Como consecuencia de la diferencia de enfoque entre ambos mundos, hay algunos
contenidos definidos en ITIL que no tienen presencia en estas normas, por estar
fuera de su alcance. Las principales diferencias se describen a continuación (véase la
figura 2.12):
• Quizás la más importante es relativa al tratamiento de la gestión de nivel de
servicio entre ISO/IEC 20000 e ITIL v2/v3. Aunque ambas comparten el
mismo nombre, en el caso de ITIL el alcance es mucho más amplio.
ISO/IEC 20000 divide de una forma más racional las funciones de la ges-
tión de nivel de servicio en 4 o 5 procesos:
1. La gestión de nivel de servicio, que en estas normas trata todo lo relativo
a los servicios desde la perspectiva interna de TI, como por ejemplo la
definición, el cumplimiento y seguimiento de los acuerdos de nivel de
servicio (SLA), la gestión del catálogo de servicios y el plan de mejora
de los servicios.
2. La generación de informes de servicio aparece como un proceso nuevo.
En ITIL se hace referencia a los informes del servicio pero como parte de
cada proceso (por ejemplo la gestión de la disponibilidad) y no se trata
de un proceso separado.
3. El proceso de relaciones con el negocio (el definido en estas normas se
corresponde únicamente a las relaciones con el cliente, que se llevan a
cabo en la gestión de nivel de servicio de ITIL).
4. El proceso de planificación e implementación de nuevos servicios o de
servicios modificados.
5. Incluso en la v2 se llega a asignar la gestión de los contratos con los sumi-
nistradores a este proceso en lo relativo al respaldo de los niveles de servi-
cio pactados con el cliente. En la v3 como en ISO 20000 aparece un pro-
ceso nuevo específico para la gestión de suministradores.
• En ISO/IEC 20000 los procesos de la continuidad del servicio y la gestión

de la disponibilidad se unifican, pues los requisitos entre ambos están bas-
tante relacionados. En ITIL, la continuidad del servicio y la gestión de la dis-
ponibilidad son procesos separados.
• En relación a la gestión económica, ISO/IEC 20000 trata únicamente la rea-
lización de presupuestos y contabilidad analítica de costes en TI. El cobro
por el servicio (charging), incluido en ITIL, no es aplicable para algunas
organizaciones y por ello no se contempla en estas normas.
• Las Normas ISO/IEC 20000 incluyen los requisitos para la gestión de la segu-
ridad de la información, haciendo referencia a los requisitos de la Norma
ISO/IEC 27001 sobre gestión de la seguridad de la información. ITIL v2
incluye un libro sobre la de gestión de la seguridad, con una alineación relativa
con la Norma ISO/IEC 27001. ITIL v3 se trata la seguridad como un proceso.
• La gestión de la capacidad en ISO/IEC 20000 no hace ninguna distinción
entre diversos tipos de capacidad. ITIL establece una distinción entre la
capacidad del recurso, la del servicio y la del negocio.

Gestión del cambio
Proceso Procesos
Área / Proceso 20000 v2 v3

Estrategia del servicio — — Sí
Diseño del servicio 88% 75% Sí
Libros ITIL v3
Construcción del servicio — — —

Transición del servicio 36% 36% Sí
Operación del servicio 33% 33% Sí
Mejora continua del servicio Sí Sí Sí
Sistema de gestión del servicio de TI Sí — —
Planificación e implementación de la
Sí Sí —
Planificación e implementación de nuevos
Sí — Sí (1)
servicios o de servicios modificados
Gestión de nivel de servicio Sí Sí Sí
Generación de informes del servicio Sí Por cada proceso
Gestión de la continuidad y disponibilidad del
Estructura ISO 20000
Sí Sí Sí
servicio
Elaboración de presupuestos y contabilidad
Sí Sí Sí
de los servicios de TI
Gestión de la capacidad Sí Sí Sí
Gestión de la seguridad de la información Sí Sí Sí
Gestión de las relaciones con el negocio Sí En gest. nivel servicio
Gestión de suministradores Sí (2) Sí
Gestión del incidente Sí Sí Sí
Gestión del problema Sí Sí Sí
Gestión de la configuración Sí Sí Sí
Gestión del cambio Sí Sí Sí
Proceso de gestión de la entrega Sí Sí Sí
(1)
En ITIL v3 la creación de nuevos servicios está embebida en el concepto de ciclo de vida del servicio.
(2) En ITIL v2 la gestión de suministradores se trata en el libro ITIL Business Perspective publicado por OGC.
Figura 2.12. Comparativa ente los procesos ISO/IEC 20000 e ITIL v2 y v3

(en porcentaje se indica el grado aproximado de cobertura)
• En ISO/IEC 20000 la gestión de los activos está cubierta por disposiciones

en la gestión de la configuración, alineándose con los libros Soporte del Servicio
y Provisión de Servicio de ITIL v2, que además trata la gestión de los activos
software en una publicación separada. Mientras que la v3 une la gestión de
activos al proceso de gestión de la configuración.
• En ISO/IEC 20000 la gestión de la Biblioteca de Software Definitivo (DSL)
se le asigna al proceso de gestión de la configuración, en ITIL v2 es gestio-
nada por la entrega.
• En ISO/IEC 20000 no se describen funciones o unidades típicas en TI. En
v2 sólo se describió en la función del service desk, mientras que en v3 en el
libro Operación del Servicio se amplía la lista identificando 4 áreas: centro de
servicio al usuario, gestión técnica, gestión de operaciones de TI y gestión
de aplicaciones.
• En ISO/IEC 20000 se define el proceso planificación e implementación de
nuevos servicios o de servicios modificados. En ITIL v2 no existe este
importante proceso, mientras que en ITIL v3 hay que indagar entre los
libros Diseño del Servicio y Transición del Servicio (versiones y despliegues)
para encontrar una secuencia parecida.
• Otra diferencia está en el alcance de los contenidos, pues en ITIL se incluyen
ejemplos de flujos de los procesos, entradas, actividades y salidas de los mis-
mos. Ejemplos de roles, factores críticos de éxito y métricas e indicadores.
3 El Sistema de Gestión
del Servicio de TI (SGSTI)
Capítulo 3


SGSTI
3. El Sistema de Gestión del Servicio de TI (SGSTI) 81
El sistema de gestión es el conjunto de políticas, procesos, procedimientos, instruc-

ciones de trabajo y recursos (humanos y materiales) necesarios para la correcta ges-
tión del servicio de TI. Se podría decir que el sistema de gestión es “la ley” hasta su
mínimo detalle a implantar.
El objetivo de este sistema de gestión es conseguir que la provisión y prestación de
los servicios de TI se realicen de una manera eficaz. Para ello se dota de unas políti-
cas y un conjunto procesos, procedimientos y normas de trabajo que fijan el marco
de trabajo para toda la organización del proveedor de servicios de TI. Todo ello
según lo establecido por las Normas ISO/IEC 20000.
A la hora de diseñar e implantar un sistema de gestión de servicios de TI, estas nor-
mas estructuran las directrices entorno a tres ejes básicos:
• Responsabilidades de la dirección. Su finalidad es conseguir el compro-
miso y la participación activa de todos los miembros de la dirección de la
organización durante toda la vida del sistema de gestión.
• Requisitos de la documentación. Establece los criterios que deben seguirse
para ejecutar los procesos y evidenciar que los trabajos se realizan siguiendo
dichos criterios.
• Competencia, concienciación y formación. Se centra en la adecuada ges-
tión de los recursos humanos, necesaria para la implantación de los proce-
sos. Para ello se elabora la definición de los perfiles, la asignación de respon-
sabilidades y la gestión de la formación. Todas estas actividades se realizan
siempre teniendo en cuenta el principio de comunicación/motivación.
SGSTI
3.1. El sistema de gestión de tecnologías de

la información
Figura 3.1. Aspectos básicos del sistema de gestión de TI
En este capítulo se presenta una descripción sobre qué es un sistema de gestión de

TI, qué elementos lo conforman, qué temas clave están especificados en las normas
y un resumen de los puntos más relevantes de cara a su implantación (véase la
figura 3.1). Se descubrirá la necesidad imperiosa de llevar a cabo la transformación
y gestión de las TI, utilizando un modelo de gestión probado con éxito en otros
ámbitos que han seguido las directrices de la normativa internacional definida en la
Norma UNE-EN ISO 9001.
Si alguien es ajeno o no estuviera familiarizado con el mundo de la calidad y la
Norma UNE-EN ISO 9001 Sistemas de gestión de la calidad. Requisitos, le será difí-
cil entender qué es un “sistema de gestión”. Para el profesional de TI es importante
entender claramente el significado de este término, pues aporta una sistemática
para organizar las actividades y obliga a formalizar, de extremo a extremo, todas las
tareas de TI, e incorpora un proceso de mejora continua. Entender su necesidad,
permitirá a los gestores de TI apoyarse y aprovechar la experiencia de los profesio-
nales de la calidad para mejorar sus servicios.
El término “sistema de gestión” proviene del inglés “management system” que repre-
senta un modo o forma de gestionar, o una manera formalizada de realizar las
cosas. Así, “IT management system” o “el sistema de gestión de TI” correspondería
a una forma normalizada para gestionar los trabajos que se realizan en TI, se
corresponde a la forma de hacer, trabajar y gestionar. La abreviatura que se ha acu-
ñado para el sistema de gestión de TI es SGSTI (Sistema de Gestión del Servicio
de TI). Es frecuente encontrar otras siglas relacionadas con este concepto, como
son: SGC (Sistema de Gestión de la Calidad), SGS (Sistema de Gestión de Servi-
cios) o SMS (Service Management System).
Se entiende el sistema de gestión de TI como el propio modelo de hacer o trabajar
en TI. Lo que cotidianamente se expresa como “vamos a implantar ITIL”, “vamos a
implantar ISO/IEC 20000”, “hay que hacer un proyecto para mejorar los servicios
de TI”, “esta es nuestra forma de trabajar en esta casa”, “el departamento de infor-
mática se gestiona en base a estos procedimientos”, etc. todas ellas son maneras de
expresarse en TI y expresan de alguna forma el concepto de “sistema de gestión
de TI” utilizado en los ámbitos de calidad. Por tanto, siendo como es la esencia de
ISO/IEC 20000 o ITIL, este sistema se define, se implanta y se mejora.
Quizá lo que más despista a los profanos es el término “sistema” pues, inconscien-
temente, parece que induce a pensar en una herramienta o algo parecido, pero no
es sólo esto. El sistema de gestión recoge la nueva forma de trabajar, de relacionarse
y de prestar servicios en TI. Si este sistema se ha creado siguiendo los principios,
los procesos y los requerimientos específicos para TI establecidos en las Normas
ISO/IEC 20000, habremos constituido el sistema de gestión de TI o SGSTI.
Desde la perspectiva de los elementos que lo componen, el sistema de gestión se
definiría como: “el conjunto de políticas, procesos, procedimientos e instrucciones
de trabajo, necesarios para la correcta gestión del servicio de TI”.
Desde una perspectiva integral del proveedor de TI, el sistema de gestión se vería
como: “el conjunto de elementos interrelacionados de una organización de tecno-
logías de la información por los cuales se lleva a cabo de forma normalizada su acti-
vidad de servicio en la búsqueda de la satisfacción de sus clientes”. Además, el con-
cepto de sistema de gestión conlleva que las actividades se normalicen en procesos
y que todos los procesos trabajen conjuntamente de una manera coordinada y con
un objetivo común, evitándose pasar de una estructura de departamentos estancos
a otra de procesos inconexos.
Con independencia de la definición utilizada, el objetivo y alcance del sistema de
gestión es el mismo.
A partir de ahora, el mundo técnico debe asumir como parte de su día a día este nuevo
concepto de “sistema de gestión de TI” o SGSTI, que equivale a gestionar el servicio
SGSTI
de TI siguiendo los procesos y formas de hacer formalizadas en la organización

del proveedor de servicios de TI. Es un sistema “vivo” en constante evolución, pues
establece lo que hay que implantar y recoge evidencias de la actividad realizada.
La figura 3.2 muestra la estrecha correlación que existe entre el SGSTI y la ejecu-
ción del trabajo diario del proveedor de TI. Nos encontramos ante un sistema de
gestión que establece los procesos de funcionamiento de TI. Estos procesos deben
estar lo suficientemente soportados por herramientas que permitan su gestión efi-
caz y su incorporación al día a día.
Figura 3.2. El sistema de gestión define el modelo de trabajo a seguir

por el proveedor de TI
También hay que entender que estas normas y marcos de referencia del mercado
(ISO/IEC 20000, ITIL, etc.) aportan directrices y recomendaciones; pero no son
utilizables, como tal, directamente en la empresa. Requieren concretarse en proce-
sos y procedimientos, que son los instrumentos sobre los que se articula la gestión
de la actividad. Además, para que sean de verdad útiles, la aplicación de todos estos
estándares debe adaptarse a las particularidades de cada empresa (tamaño, negocio,
cultura, estrategia, etc.).
Por ello, todo proveedor u organización de TI debe crear su propio sistema de ges-
tión que tenga en cuenta cómo adaptar las normas a todas las particularidades pro-
pias de cada empresa.
Si se quiere mejorar seriamente la calidad de los servicios de TI, es imprescindible

que se defina e implemente un sistema de gestión específico. Por ello, las Normas
ISO/IEC 20000 establecen que la transformación de TI hacia una mayor calidad
en sus servicios, se articule en torno a un sistema de gestión. En la figura 3.3 se
muestra un resumen introductorio al sistema.
Sistema de Gestión del Qué aporta:

Servicio de TI (SGSTI) • Formaliza en la organización la
implantación de la gestión del servicio.
• Implantación de lo general
Definición: (estrategia y políticas) a lo particular
(procedimientos).
Gestión del servicio de TI siguiendo
los procesos y formas de hacer • Medio para alcanzar la eficiencia
formalizadas en la organización del y la calidad deseadas.
proveedor de TI, buscando la • Permite la alineación con los sistemas
eficiencia y calidad deseadas. de gestión de la calidad (ISO 9001)
de la empresa.
Objetivo: • Genera un sistema documental en el
que se recoge formalmente toda la
Proveer un sistema de gestión que información necesaria para soportar
incluye las políticas y el marco el modelo de gestión.
de trabajo para hacer posible una
efectiva gestión e implementación • Impone rigor en la definición, en
el seguimiento y en la captura de
de todos los servicios de TI.
registros y evidencias.
• Imprescindible para la certificación
ISO/IEC 20000.
Figura 3.3. Introducción al sistema de gestión de TI
El sistema de gestión es un medio para la transformación de la organización. Ade-

más de las estrategias y políticas de mejora, recoge y formaliza todos los documen-
tos y registros necesarios. Los requisitos para los sistemas de gestión generales de
la empresa se definen en la Norma UNE-EN ISO 9001. Tener implantado un sis-
tema de gestión, según esta norma, ayudaría enormemente en la implantación de
ISO/IEC 20000. Aunque las Normas ISO/IEC 20000 contienen todos los reque-
rimientos para montar un sistema de gestión propio, sin tener que apoyarse en otra
norma, el Sistema de Gestión del Servicio de TI (SGSTI) debería estar integrado
en el modelo general de gestión de la empresa acorde con ISO 9001, si existiera
(véase la figura 3.4).
SGSTI
Cultura de Buenas prácticas Objetivos del Capacidad

la empresa de la empresa negocio y de TI y recursos
Sistema de gestión general de la empresa (SGC según ISO 9001)
Tecnologías de la información
Gestión y operación
SG de otras áreas
del servicio de TI
de la empresa
SGSTI
Gestión servicio
Calidad y y su prestación
mejora continua
ITIL
ISO 9001
ISO 20000
Figura 3.4. El sistema de gestión de TI debe estar integrado con el sistema

de gestión general de la empresa
Al definir las formas de hacer en el sistema de gestión se deben tener en cuenta

también las particularidades de la empresa, como por ejemplo:
• La cultura de la empresa.
• Las buenas prácticas existentes en la empresa.
• Los objetivos del negocio y los objetivos de TI.
• Las capacidades, conocimientos y disponibilidad de recursos del propio pro-
veedor de TI.
El sistema de gestión es un elemento esencial para obtener la certificación ISO/IEC

20000 en una organización de prestación de servicios de TI, pues registra toda la
documentación y evidencias que el auditor exigirá en el proceso de certificación.
Como cabía esperar, las directrices de las Normas ISO/IEC 20000, no sólo especi-
fican los requisitos de la documentación, sino que además exigen otros aspectos
esenciales para que la mejora de los servicios se produzca en realidad, como son,
por una parte, la implicación y compromiso de la dirección, y por otra, la concien-
ciación y formación de las personas. A continuación se detallan los tres aspectos
clave requeridos en estas normas (véase la figura 3.5):
• Implicación y compromiso de la dirección en el proceso de cambio (apar-

tado de responsabilidades de la dirección).
• Definición de la documentación del sistema de gestión (apartado de requisi-
tos de la documentación).
• La importancia de la gestión de los recursos humanos para que se produzca
el cambio (apartado de competencia, concienciación y formación).
Implicación
de la dirección
AR PARA
S LÍDERES
SGSTI
Documentación Cambio cultural
Figura 3.5. Aspectos esenciales en la implementación del

sistema de gestión de TI
Responsabilidades de la dirección
La mejora de los servicios de TI pasa por implantar los procesos que forman el sis-
tema de gestión de TI en todo su detalle. Este enfoque en torno a los procesos va a
suponer la introducción de cambios sustanciales, tanto desde el punto de vista cul-
tural en la forma de trabajar de las personas como, en algunos casos, profundos
cambios organizativos. Ante esta transformación de TI (o del proveedor de servi-
cio de TI en terminología de la norma) resulta imprescindible contar con el apoyo,
compromiso y participación de la alta dirección de la empresa y de TI, como dina-
mizadora esencial de todo este proceso.
En líneas generales, las empresas tienen sus grupos internos (calidad, procesos, de
mejora, explotación, etc.) que frecuentemente inician por si mismas las actividades
SGSTI
de transformación de TI hacia una organización centrada en el cliente, que presta

servicios y se estructura en base a procesos. Tanto las directrices de las Normas
ISO/IEC 20000, como las mejores prácticas del mercado, dejan muy claro que este
comienzo es loable, pero insuficiente; debe ser la dirección de TI y de la empresa
los que lideren la transformación del área de TI. Por ello, en la norma aparece este
apartado específico dedicado a las responsabilidades de la dirección en todo el pro-
ceso de transformación.
Las Normas ISO/IEC 20000 establecen de manera general las responsabilidades
que debe ejercer la dirección, de cara a permitir la implantación y el adecuado
mantenimiento del sistema de gestión y, a la vez, las convierte en requisitos clave
para la obtención de la certificación. Este es un requisito clave que se debe cum-
plir si se desea obtener la certificación. En los casos en que ya exista un sistema de
gestión (por ejemplo, el sistema de gestión de la calidad) que establezca las res-
ponsabilidades de la dirección, habrá que verificar que lo establecido es consis-
tente y coherente con lo requerido en ISO/IEC 20000. Garantizar este alinea-
miento permitirá ir construyendo un sistema integrado o unificado de gestión en
la empresa.
El papel de la dirección para asegurar que las mejores prácticas se adoptan y man-
tienen en los procesos es fundamental para cualquier proveedor de servicio que
quiera cumplir con los requisitos de ISO/IEC 20000-1:
UNE-ISO/IEC 20000-1
La alta dirección debe proveer, a través del liderazgo y de acciones, evidencias de

su compromiso para desarrollar, implementar y mejorar sus capacidades de gestión
del servicio dentro del contexto de los requisitos de negocio de la organización y de
los requisitos de los clientes.
La dirección debe:
a) establecer la política de la gestión del servicio, sus objetivos y planes;
b) comunicar la importancia de cumplir con los objetivos de gestión del servicio
y la necesidad de la mejora continua;
c) asegurar que los requisitos del cliente se determinan y se cumplen con el obje-
tivo de mejorar la satisfacción del cliente;
d) designar un miembro de la dirección como responsable para la coordinación
y gestión de todos los servicios;
e) determinar y proveer recursos para planificar, implementar, monitorizar, revisar
y mejorar la provisión y la gestión de los servicios, por ejemplo, contratando el
personal apropiado o gestionando la rotación de personal;
f) gestionar los riesgos para la organización de la gestión del servicio y para los
servicios; y
g) llevar a cabo revisiones de la gestión del servicio, a intervalos planificados,
para asegurar la continuidad de su idoneidad, su adecuación y su efectividad.
UNE-ISO/IEC 20000-2
El papel de la dirección para asegurar todos los niveles del plan de gestión del
que las mejores prácticas son adoptadas servicio.
y mantenidas en los procesos es funda- El rol de responsable senior debería
mental para cualquier proveedor del estar al frente de los recursos designa-
servicio que quiera cumplir con los requi- dos para las actividades de mejora del
sitos de la Norma ISO/IEC 20000-1. servicio, bien sean actividades conti-
Para asegurar el compromiso de la nuas o con un enfoque de proyecto.
dirección se debería identificar un res- El responsable senior debería estar apo-
ponsable a nivel de alta dirección como yado por un grupo encargado de la
responsable de los planes de gestión del toma de decisiones que tenga la sufi-
servicio. Este responsable senior debe- ciente autoridad para definir la política
ría responsabilizarse de la entrega a y para hacer cumplir sus decisiones.
Como indican estas normas, para asegurar el compromiso se debería identificar un

responsable senior (a nivel de alta dirección) de la implantación de la gestión del
servicio. Este “patrocinador” del sistema de gestión debe responsabilizarse de la
ejecución y éxito de esta transformación. Debe estar al frente de los recursos desig-
nados, bien sean actividades continuas o con un enfoque de proyecto. También
debe estar apoyado por un grupo de toma de decisiones con suficiente autoridad
para definir la política y para hacer cumplir sus decisiones.
El papel de la dirección, por tanto, es ser protagonista desde el primer momento
en que se decide acometer el diseño e implantación de un sistema de gestión de ser-
vicios de TI. De todas y cada una de estas actividades habrá que dejar evidencia
documental, que se registrará en el propio sistema de gestión, para las auditorias
posteriores. Por ejemplo: actas de reuniones en las que se traten asuntos anterior-
mente mencionados, documentos de políticas firmados y comunicados a todos los
niveles, etc.
SGSTI
Requisitos de la documentación
Para que el sistema de gestión sea eficaz es necesario dar respuesta a dos aspectos
clave. El primero de ellos es definir y documentar adecuadamente las actividades,
funciones y responsabilidades que deben desempeñarse. El segundo es contar con
la participación activa y efectiva del personal implicado en el servicio.
El primer paso de cara a implantar un sistema de gestión es crear una estructura
documental. Permite llevar registro y control de todas las actividades realizadas,
evaluar la eficiencia del sistema y servir para la toma de decisiones sobre acciones
correctivas o preventivas. Todas las actividades desarrolladas deben documentarse.
A este respecto estas normas establecen:
UNE-ISO/IEC 20000-1
Los proveedores del servicio deben facilitar documentos y registros para asegurar
una planificación, operación y control de la gestión del servicio efectivas. Esto debe
incluir:
a) políticas y planes de la gestión del servicio documentados;
b) acuerdos del nivel de servicio documentados;
c) procesos y procedimientos documentados requeridos por esta norma; y
d) registros requeridos por esta norma.
Deben establecerse los procedimientos y las responsabilidades para la creación,

revisión, aprobación, mantenimiento, eliminación y control de los diferentes tipos de
documentos y registros.
Nota: La documentación puede estar en cualquier forma o tipo de soporte.
Los soportes en los que esté recogida la documentación deben ser los adecuados
para permitir un normal funcionamiento del sistema. Por ejemplo, si nuestra orga-
nización recibe mensualmente 1.000 incidentes, no pueden quedar registrados úni-
camente en un cuaderno. Deberán registrarse en una herramienta informática
dimensionada de acuerdo a las necesidades del proceso y de la organización.
La documentación del sistema contribuye a:
• Lograr la conformidad con los requisitos del cliente y la mejora de la calidad.
• Proveer la formación adecuada.
• La repetibilidad y la trazabilidad.
• Proporcionar evidencias objetivas.
• Evaluar la eficacia y la adecuación continua del sistema de gestión de servi-
cios de TI.
Para gestionar de una forma eficaz la documentación del sistema es necesario ela-
borar un procedimiento que diga cómo y quién crea los documentos, los revisa,
aprueba, mantiene y elimina.
Estructura del sistema de gestión

En cuanto a su contenido, un sistema de gestión de servicios de TI aloja el conjunto
de documentación que integra y gestiona toda la información necesaria para el fun-
cionamiento eficaz de los procesos, así como para la mejora continua. Esto abarca
desde la estrategia definida por la dirección hasta los aspectos más detallados como,
por ejemplo, planes de actuación, la definición de los procesos, procedimientos,
instrucciones de trabajo, los registros, las métricas, etc. Todo ello se debe incorpo-
rar en una o varias herramientas de soporte del sistema de gestión. Además, se
deben establecer los procedimientos de cómo se gestionará y actualizará este sis-
tema (manual del sistema de gestión). En la figura 3.6 se muestra un ejemplo del
contenido de un sistema de gestión para TI.
El sistema de gestión debería contemplar los siguientes contenidos:
• Manual del SGSTI, que incluye:
– Declaraciones documentadas de una política de gestión de servicios: man-
dato de la alta dirección, estrategia, políticas y objetivos.
– El plan de acción.
– La asignación de recursos para su definición y evolución. Constitución de
un equipo de trabajo para definir y evolucionar el SGSTI.
– El modelo de los procesos de TI.
– Estructura organizativa de TI.
• Manual de procesos y procedimientos del SGSTI:

– Los procesos completamente documentados.
SGSTI
Figura 3.6. Componentes y contenidos habituales

en un sistema de gestión de TI (SGSTI)
– Roles, competencias y desarrollo de la estructura organizativa.

– Los procedimientos detallados, documentos requeridos por la organiza-
ción para asegurarse de la eficaz planificación, operación y control de sus
procesos.
– Instrucciones de trabajo.
• Registros de los procesos:

– Las evidencias o registros requeridos por la Norma ISO/IEC 20000-1
para la certificación de la conformidad (véase apartado 11.2).
– Las métricas de los procesos y de los servicios.

– Las evaluaciones de madurez de la actividad y auditorías.
• La gestión del propio SGSTI:

– El manual sobre la propia organización del sistema de gestión.
Como es lógico, los contenidos del sistema de gestión se deben alojar en una herra-
mienta de soporte documental que permita una gestión de versiones y un control
de los cambios a los contenidos.
El manual del SGSTI es el documento principal que recoge la estrategia de la
empresa, la estructura, responsabilidades, actividades, recursos, modelo de proce-
sos, etc., que una organización establece para llevar a cabo la gestión de los servi-
cios de TI. Físicamente puede ser un único documento o una estructura documen-
tal basada en versiones.
El manual de procesos y procedimientos del SGSTI contiene la definición especí-
fica de todos los procesos, procedimientos e instrucciones de trabajo que aseguren
la adecuada gestión de servicios de TI. Nuevamente, la denominación de “manual”
no quiere decir que sea un documento único, pues estará formado por un conjunto
completo de documentos. Pero, eso sí, con un adecuado control de versiones. El
manual del SGSTI nos dice: ¿qué? y ¿quién?; mientras que el manual de procedi-
mientos indica: ¿cómo? y ¿cuándo?
La definición de los procesos es una de las principales actividades para el cambio
en el proveedor de TI. Para la definición de procesos se recomienda la utilización
de una herramienta específica de diagramación con soporte para poder describir su
contenido. En la figura 3.7 se muestra un ejemplo de la estructura documental para
definir un proceso.
Cuando sea necesario especificar en detalle una actividad o una tarea se utiliza el
documento denominado “instrucción de trabajo”, que describe la forma en la que
se debe realizar un trabajo. En la figura 3.8 se muestra el ejemplo del contenido de
una de ellas.
SGSTI
Índice del documento de definición

de un proceso
1. Introducción
• Objetivo del documento. Documentos
de referencia.
2. Definición del proceso

• Misión. Objetivos. Alcance.
• Ubicación del proceso (en el mapa general).
• Conceptos clave del proceso.
3. El proceso en detalle
• Diagrama de flujo del proceso.
• Diagrama de flujo de los subprocesos.
• Diagrama de flujo de las actividades.
• Detalle de cada actividad y E/S.
• Relaciones con otros procesos.
4. Roles y responsabilidades
• Roles y sus responsabilidades.
• Matriz RACI.
5. Documentos de soporte y formularios

6. Elementos de control del proceso
• Métricas de gestión, métricas de actividad.
7. Cómo implantar el proceso

• Factores críticos de éxito. Requisitos para
herramientas.
8. Anexos
Figura 3.7. Ejemplo del índice del documento para la definición de un proceso
Instrucción de trabajo para la

clasificación y priorización del incidente
1. Introducción.
2. Objeto.
3. Campo de aplicación.
4. Documentos relacionados.
5. Definiciones.
6. Pautas de implantación.
7. Prioridad de los incidentes.
8. Tabla de prioridades.
9. Lista de umbrales basada en prioridades.
10. Categoría de un incidente.
Figura 3.8. Ejemplo del índice de una instrucción de trabajo
Registros de la actividad diaria y evidencias del

cumplimiento
Un registro es el resultado tangible de la actividad de TI y de los procesos. Por
ejemplo, el incidente registrado en la herramienta de gestión del incidente, una
encuesta de satisfacción del cliente, una petición de cambio RFC, unas medidas,
un informe del servicio, un SLA, un elemento en la base de datos de configuración,
etc. También son registros la documentación del sistema y sus evoluciones. No hay
un almacenamiento específico o dedicado de registros. Éstos quedan guardados en
las propias herramientas o mecanismos de soporten la gestión de TI. Además,
como premisa básica, los registros deben estar disponibles, fácilmente identifica-
bles y recuperables.
Los registros, al ser el resultado de la actividad, retienen el conocimiento de la
organización de TI.
Una aplicación importante de los registros es la de proporcionar evidencias de la
conformidad del proveedor de TI con los requisitos de las normas.
SGSTI
Las evidencias son cualquier documento o prueba que proporcione una demostra-
ción objetiva del cumplimiento de las normas por el proveedor de TI. Las eviden-
cias se obtienen de los registros y de cualquier otra forma que permita probar que
se cumplen los requisitos (por ejemplo, un documento, una comprobación, etc.).
En relación a las evidencias, ISO/IEC 20000-2 indica:
UNE-ISO/IEC 20000-2
El responsable senior debería asegurar a) políticas y planes;

que las evidencias necesarias están dis- b) documentación del servicio;
ponibles para una auditoria de las polí-
ticas, planificaciones y procedimientos c) procedimientos;
de la gestión del servicio y de cualquier d) procesos;
actividad relacionada con ellos.
e) registros de control de procesos.
Gran parte de las evidencias de los planes
y operaciones de la gestión del servicio se Debería existir un proceso para la crea-
deberían encontrar en forma de docu- ción y gestión de los documentos para
mentos, los cuales pueden ser de cual- ayudar a asegurar que se satisfacen las
quier tipo y estar en cualquier formato o características descritas.
soporte que sea adecuado para su fin.
La documentación se debería proteger
Los siguientes documentos son conside- de daños, debidos, por ejemplo, a
rados normalmente como válidos para escasas condiciones del entorno donde
servir de evidencias de la planificación se encuentran y a desastres en los siste-
de la gestión del servicio: mas informáticos.
Los registros están ligados al control de la actividad de TI, mientras que las eviden-
cias se utilizan directamente para la certificación y las auditorías.
Competencia, concienciación y formación

En este apartado sobre el sistema de gestión, en estas normas se concentran las
directrices y recomendaciones estratégicas para que la evolución de los servicios
tenga éxito. Al principio de este capítulo se hace hincapié en que el cambio debe se
liderado por la dirección de la empresa. En la segunda parte del mismo se definen
la gestión documental que da rigor a todo el proceso, para centrarse, en este último
apartado, en las personas que forman el área de TI.
Tanto estas normas como ITIL, conllevan la transformación de las formas de hacer
de un conjunto o equipo, más o menos numeroso, de personas. Se pretende cambiar
la forma de trabajar de las personas que componen TI y la forma en que estas sienten
cuál es su misión en la organización. El cambio se orienta hacia una sistemática de
trabajo estructurada, centrada en los clientes, basada en procesos y articulada en
torno a servicios.
Para que esta transformación se pueda llevar a cabo, hay que poner la máxima aten-
ción y esfuerzo en el equipo humano que está involucrado en los servicios. Pues es
este conjunto de personas el que debe evolucionar sus formas de hacer hacia los
esquemas estandarizados por el mercado.
Por lo tanto, para conseguir una eficaz implantación del sistema de gestión, es
necesario llevar a cabo la adecuada gestión de los recursos humanos. Para ello,
debemos responder a tres preguntas:
• ¿Cuáles son las necesidades en cuanto a roles y funciones que requiere el sis-
tema de gestión?
• ¿Qué perfiles existen dentro la organización?
• ¿Cómo se va a cubrir el posible desfase entre ambos aspectos?
Para responder a estas preguntas ISO/IEC 20000-1 establece los siguientes requi-
sitos:
UNE-ISO/IEC 20000-1
Se deben definir y mantener todos los roles y responsabilidades de la gestión del

servicio, junto con las competencias que sean requeridas para su ejecución efec-
tiva.
Las competencias y necesidades de formación del personal deben revisarse y gestio-
narse para permitir al personal llevar a cabo sus roles de forma efectiva.
La alta dirección debe asegurar que sus empleados son conscientes de la relevancia
e importancia de sus actividades y de cómo deben contribuir a la consecución de
los objetivos de la gestión del servicio.
El desfase entre roles y responsabilidades que son necesarios desempeñar se debe

cubrir mediante la realización de acciones de formación e información.
El personal que realiza el trabajo en el ámbito de la gestión del servicio debería ser
competente gracias a la formación recibida, a las habilidades y a las experiencias
adecuadas.
SGSTI
UNE-ISO/IEC 20000-2
El personal que realiza el trabajo relativo del más amplio contexto de nego-
a la gestión del servicio debería ser com- cio y de cómo contribuyen a la
petente para esta función gracias a la consecución de los objetivos de
educación recibida, a la formación, las calidad;
habilidades y la experiencia adecuadas.
c) mantener registros apropiados de
El proveedor del servicio debería: la educación, formación, habili-
dades y experiencia;
a) determinar las aptitudes necesa-
rias para cada rol en la gestión d) proveer formación o llevar a cabo
del servicio; otras acciones para satisfacer
estas necesidades;
b) asegurar que el personal es cons-
ciente de la relevancia e impor- e) evaluar la efectividad de las ac-
tancia de sus actividades dentro ciones realizadas.
Como no podía ser de otra forma, ISO/IEC 20000-2 hace especial hincapié en
el desarrollo profesional y de las competencias de las personas que forman parte
de TI:
UNE-ISO/IEC 20000-2
Desarrollo profesional. El proveedor y frente al conjunto de objetivos

del servicio debería desarrollar y mejo- de la calidad del servicio;
rar las competencias profesionales de b) planificación: con el objetivo de
su fuerza de trabajo. Entre las medidas dotar de personal a los servicios
tomadas para conseguir esto, el prove- nuevos o a aquellos que se hayan
edor del servicio debería incluir lo ampliado (también contratando
siguiente: servicios), usando tecnología
a) contratación: con el objetivo de nueva, asignando personal de
comprobar la validez de los deta- gestión del servicio a los equipos
lles de los candidatos al puesto de desarrollo de proyecto, planifi-
de trabajo (incluyendo su cualifi- cando la sucesión y rellenando
cación profesional) y de identificar los vacíos que se generen debido
la fortalezas, debilidades y habili- a rotación anticipada del personal;
dades potenciales de los candida- c) formación y desarrollo: con el
tos frente a una descripción/perfil objetivo de identificar los requisi-
del puesto de trabajo, frente a los tos de formación y desarrollo
objetivos de la gestión del servicio dentro de un plan de formación y
desarrollo y proveer su imparti- formación, auto estudio, tutorías y forma-

ción en el momento oportuno y ción en el trabajo) y se debería desarrollar
de forma efectiva. el trabajo en equipo y las habilidades de
liderazgo. Se debería mantener un regis-
Se debería formar al personal en los astro cronológico de la formación para
pectos relevantes de la gestión del servi- cada persona, junto con las descripciones
cio (por ejemplo, a través de cursos de de la formación proporcionada.
En relación a la estrategia de contratación de personal propio de plantilla frente a la

contratación temporal, ISO/IEC 20000-2 hace unas reflexiones sobre los diferen-
tes enfoques a considerar:
UNE-ISO/IEC 20000-2
Enfoques a considerar. Para que los a) el carácter de las competencias

equipos de personal alcancen unos nuevas o modificadas: si son a
niveles apropiados de competencia, el corto o a largo plazo;
proveedor del servicio debería decidir b) la tasa de cambio en las habilida-
cuál es la proporción óptima entre las des y competencias;
contrataciones a corto plazo y de forma
indefinida. El proveedor del servicio c) los picos y los descensos espera-
debería decidir también la proporción a dos en la carga de trabajo y
alcanzar entre la contratación de nuevo la combinación de habilidades
personal con las habilidades requeridas requeridas, datos basados en la
y el reciclaje de personal ya existente. gestión del servicio y en la planifi-
cación de las mejoras del servicio;
Nota: El equilibrio óptimo entre las contratacio-
nes a corto plazo y de forma indefinida es d) disponibilidad de personal com-
particularmente importante cuando el pro- petente;
veedor del servicio está planificando como
e) tasas de rotación de personal;
proveer un servicio durante y después de
cambios a gran escala en el número y f) planes de formación.
habilidades del personal de apoyo.
Para todo el personal, el proveedor del
Los factores que se deberían considerar servicio debería revisar el desempeño a
para establecer la combinación más nivel individual al menos anualmente y
adecuada de estos enfoques incluyen: tomar las acciones oportunas.
SGSTI
Presente y futuro del Sistema de Gestión del

Servicio de TI (SGSTI)
Actualmente las empresas no son capaces de “digerir” e implementar toda la nor-
mativa y buenas prácticas ya definidas por el mercado. La progresiva maduración
del sector de las TI y de los profesionales que lo forman permitirá ir aprovechando
paulatinamente toda la normativa que está definida o se vaya definiendo.
Para ello, el sistema de gestión se debería convertir en un mecanismo intermedio
que traspase y adapte, de forma eficiente, los avances normativos de la industria a
la actividad del proveedor de TI. Este sistema intermedio, entre la normativa
externa y las formas de trabajo internas, permitirá al proveedor de TI ir incorpo-
rando paulatinamente en la organización las nuevas prácticas que de forma conti-
nua se producen en el mercado. De esta forma, el personal de TI seguirá trabajando
con su sistema de gestión y sus evoluciones, independizándose de la vorágine de
producción y revisión de mejores prácticas en las que el mercado está inmerso.
Pero para mantener actualizado el sistema de gestión, se debería contar con un
equipo específico de expertos en el análisis de la evolución de los entornos norma-
tivos que influyen en TI, para dejar que el resto de la organización se concentre en
su trabajo cotidiano. Así, la mayoría de los profesionales de TI tendrían únicamente
que conocer y aplicar el sistema de gestión de TI de su empresa, que será evolucio-
nado por este grupo de expertos en el SGSTI.
El camino a la excelencia de la gestión de las TI en la empresa pasa por construir
este único modelo, en el que se vaya incorporando toda la normativa y buenas
prácticas existentes a las formas de hacer internas. Así, el sistema de gestión de TI
debe ser un modelo más amplio, se necesita que vaya más allá de lo establecido en
ISO/IEC 20000 para poder cubrir las necesidades.
Además, en el ámbito más general de la gestión de la empresa aparece el concepto
de “sistema de gestión integrado”. En concreto, la Norma UNE 66177 Sistemas de
gestión. Guía para la integración de los sistemas de gestión hace referencia a la integra-
ción de los sistemas de gestión de calidad, medio ambiente y seguridad laboral
(ISO 9001, ISO 14001 y OHSAS 18001) y define a nivel práctico una metodolo-
gía de integración de los distintos sistemas de gestión a desarrollar por la organiza-
ción. De forma parecida, la norma británica BS-PAS 66 Specification of common
management system requirements as a framework for integration especifica los requisi-
tos para un sistema de gestión unificado marco. E incluso existe la Guía ISO 72
que es una guía de referencia para redactar normas que definen los sistemas de ges-
tión, esta guía fue adaptada como informe UNE 66172 IN.
El SGSTI se debería construir sobre el modelo de gestión de la calidad existente en la
empresa, para acabar convirtiéndose en un modelo integrado que aglutine las formas
en que la empresa gestionará sus TI (denominado aquí para clarificar como:

SGSTI+). Por ello, el SGSTI+ se afrontaría con esta visión integradora constituyén-
dose en el único sistema de gestión de TI e incorporando:
• El sistema de gestión general de las TI en base a ISO/IEC 20000, para la
gestión y operación de los servicios, contemplando las mejores prácticas
de ITIL.
• La gestión de la calidad para la construcción o desarrollo de software según
ISO 9001, UNE 71044 e ISO 90003, junto a CMMI y metodologías de
gestión de proyectos (por ejemplo, PMBOK o PRINCE2).
• El sistema de gestión de la seguridad SGSI según ISO 27001.
• La estrategia y gobierno de las TI según ISO/IEC 38500 y COBIT.
• Integrándose el SGSTI+, a su vez, en el sistema de gestión de la calidad
(SGC) general de la empresa según ISO 9001.
• Y el resto de mejores prácticas relacionadas con TI que vayan saliendo.
En la figura 3.9 se muestra una situación que es frecuente encontrar en las empre-
sas más avanzadas. En esta primera etapa de evolución en las formas de gestión de
las TI, se incorporan las normas más relevantes: para la gestión de sistemas, para el
desarrollo, para la seguridad y para el gobierno de las TI.
El SGSTI debe unificar, incorporándolos, los sistemas de gestión en el ámbito de
TI que posiblemente se estén implantando o ya se hayan implantado.
Dado que el entorno normativo está en frenética ebullición, el sistema de gestión
de TI se debería ir enriqueciendo con aquellos avances normativos que contribu-
yan a la mejora del proveedor de TI, con el fin de implantar en el quehacer coti-
diano de TI la riqueza de las formas de hacer de todos estos estándares. Así, la gestión
de todo proveedor de TI se construirá tomando en cuenta todos los estándares de
mayor relevancia para tener una gestión de las TI completamente madura (denomi-
nado aquí como: SGSTI++), como se muestra en la figura 3.10.
Después de esta visión al futuro, conviene dejar claro que en el caso de las Normas
ISO/IEC 20000 sólo se exige que se cumpla con los requisitos especificados en
ellas y no se requiere que se incorporen todos los otros estándares mencionados
anteriormente.
En los capítulos siguientes del libro se profundiza en los 14 procesos definidos en
estas normas, que son la base para la trasformación de las actividades más esencia-
les del proveedor de TI.
SGSTI

Tecnologías de la información – Sistema de gestión integrado

Gestión y operación Desarrollo de SW
SG de otras áreas Gobierno Seguridad
del servicio de TI Madurez +
de la empresa SG GOB SGSI
SGSTI SG DES.
Calidad y Gobierno Gestión servicio

Seguridad Desarrollo SW
mejora continua TI y su prestación
SPICE ISO
ISO 9001 COBIT ITIL ISO 17799
15504
CMMI for
ISO 9004 ISO 38500 ISO/IEC 20000 ISO 27001
DEV
ISO 90003
Figura 3.9. Escenario maduro con la incorporación de normativa

a la gestión de las TI (SGSTI+)

Sistema integrado de gestión del servicio de TI (SGSTI++)

SG de otras áreas Incorpora la normativa del mercado relacionada con TI
de la empresa (gobierno, gestión del servicio, desarrollo de SW, proyectos, seguridad, etc.)
Calidad y Procesos propios Medio Gobierno Gestión servicio Desarrollo Getión de

Seguridad
mejora continua del negocio ambiente TI y su prestación SW proyectos
ISO 9001 Industria CMMI SPICE ISO 17799

Services
ISO 9004 Banca ISO 14001 COBIT ISO 9003 PMBOK ISO 27001
ITIL v3
EFQM Telcos: UNE ISO 38500 ISO 12007 Prince 2 ISO 29382
eTOM ITIL v2
150004 EX PAS 77
6 Sigma Lean ISO/IEC People CMMI
20000
CMMI
Figura 3.10. Escenario previsto 2014 de uso de normativa

para la gestión de las TI (SGSTI++)
Resumen
La aportación principal de un sistema de gestión es el orden y la estandarización.
Así, toda la organización trabaja de la misma forma y con el mismo “idioma”. Todo
ello contribuye en la consecución del objetivo que tiene este sistema de gestión:
“hacer posible una efectiva gestión e implantación de todos los servicios de TI”.
El objetivo de este sistema de gestión es conseguir que la provisión y prestación de
los servicios de TI se realice de una manera eficaz y eficiente.
En la figura 3.11 se recoge una visión completa del SGSTI y su relación con el día
a día del proveedor de TI.
Figura 3.11. Visión completa del SGSTI y su relación con el día a día
del proveedor de TI
SGSTI
En la figura 3.12 se muestra a modo de resumen un ejemplo de la estructura docu-

mental de un sistema de gestión de TI.
Estructura documental del SGSTI
1. Manual del SGSTI

• El mandato de la alta dirección.
• Estrategia, política y objetivos de la
gestión de servicios TI.
• Plan de acción.
• Recursos para su definición y ejecución.
• Modelo de procesos.
• Estructura organizativa.
2. Manual de procesos y procedimientos
del SGSTI
• Manual de procesos.
• Roles y competencias.
• Manual de procedimientos.
• Instrucciones de trabajo.
3. Registros de los procesos
• Registros.
• Mediciones.
• Resultados de auditorías y evaluaciones.
4. Gestión y soporte del SGSTI
• Manual de gestión del SGSTI.
• Herramienta de soporte documental
al sistema.
Figura 3.12. Ejemplo de la estructura documental de un SGSTI

Beneficios
Implantar la gestión de los servicios de TI, utilizando los conceptos y rigor impues-
tos por el sistema de gestión, aporta importantes ventajas a la organización de TI:
• Formaliza en la organización la implantación de la gestión del servicio.
• Propone una aproximación estructurada de lo general (estrategia y políticas)
a lo particular (procedimientos).
• Da soporte a una implantación por etapas, extendida en el tiempo.
• Impone rigor en la definición, en el seguimiento y en la captura de registros
y evidencias.
• Permite la alineación con los sistemas de gestión de la calidad (ISO 9001)
de la empresa.
• Genera un sistema documental en el que se recoge formalmente toda la
información necesaria para soportar el modelo de gestión.
• La gestión documental que lo soporta es una pieza imprescindible para obte-
ner la certificación ISO/IEC 20000.
? Aplique lo aprendido
Para afianzar la comprensión del capítulo, se sugiere que responda a las
siguientes preguntas 1:
• ¿Sabe qué sistemas de gestión hay implantados en su empresa u
organización?
• ¿Qué aporta un sistema de gestión a las organizaciones de TI?
• ¿Cuál es la diferencia entre el Sistema de Gestión del Servicio de TI
(SGSTI) y el modelo de procesos ISO/IEC 20000?
1
Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
otros lectores en el foro web del libro: http://www.LibroISO20000.es.
4
Capítulo 4
Planificación e
implementación de
la gestión del servicio


PDCA
4. Planificación e implementación de la gestión del servicio 109
La transformación del proveedor de TI hacia un modelo orientado a servicios y

ajustado a las necesidades del negocio pasa por la implantación de formas más
organizadas y eficientes de gestionar la tecnología. El reto de las organizaciones se
centra en ser capaces de cambiar evolucionando hacia modelos más industrializa-
dos de trabajo en TI, alejándose de los individualismos y de las incertidumbres
habituales. Como se ha tratado en capítulos anteriores, la adopción de las prácticas
de ISO/IEC 20000 junto con otras buenas prácticas del mercado (como ITIL) es
el camino más acertado para el avance.
El problema surge cuando un proveedor de TI se plantea la forma de abordar esta
transformación interna de su organización. La experiencia demuestra que la trans-
formación con base a ITIL y a las Normas ISO/IEC 20000 puede llevar varios
años de trabajo continuo, aunque la certificación se pueda conseguir antes. Ade-
más, conviene ser conscientes de que se está empezando un camino de mejora con-
tinua en la organización. Antes de terminar esta implementación seguramente
habrá que abordar en paralelo otros proyectos de mejora, por ejemplo: la seguri-
dad (en base a ISO/IEC 27001), el gobierno de las TI (ISO/IEC 38500 y
COBIT), el desarrollo de aplicaciones (ISO/IEC 15504 ó CMMI for Develop-
ment), etc.
Los requisitos y guía del apartado 4 de las Normas ISO/IEC 20000 y este capítulo
del libro, están centrados en ayudar a que la planificación e implementación de la
gestión del servicio se alcance con éxito. Además, se enriquece con experiencias
basadas en otras organizaciones pioneras que abordaron o están abordando esta
transformación.
Para entenderlo mejor, el título del capítulo 4 de las normas, “Planificación e imple-
mentación de la gestión del servicio”, se podría también entender como “implanta-
ción de las Normas ISO/IEC 20000” o bien “implantación del sistema de gestión
(SGSTI)”. Es decir, la implantación de las normas pasa por planificar su implanta-
ción, hacer la implantación (que incluye la definición completa del SGSTI), verifi-
car si se han alcanzado los objetivos para establecer las medidas correctoras necesa-
rias, y actuar iniciando un plan de mejora continua.
El apartado 4 de las normas es bastante autoexplicativo y no necesita aclaraciones
especiales, por lo que en este capítulo del libro se ha decidido complementar lo
indicado en las normas con la experiencia de los autores en las implementaciones y
parte de lo recogido en ITIL.
PDCA
4.1. Cómo planificar e implementar la gestión

del servicio
Figura 4.1. Planificación e implementación de la gestión del servicio

siguiendo el ciclo PDCA
Las Normas ISO/IEC 20000, al igual que muchas otras normas internacionales,
establecen que la implantación de los procesos para la gestión del servicio se estruc-
ture en las cuatro etapas identificadas por las siglas PDCA, muy utilizadas en gestión
de la calidad (véase la figura 4.1). Estas normas se centran en definir los requisitos y
recomendaciones a tener en cuenta para la implantación de los procesos establecidos
en los sistemas de gestión, ordenados en cada una de estas 4 etapas del PDCA.
El ciclo PDCA representa una forma de organizar los cambios o las acciones de
mejora en las organizaciones. Es una estructuración sencilla en 4 pasos y viene a
recordar que, además de planificar e implementar los cambios, hay que comprobar
el éxito de las acciones, y si hay algo que corregir o prevenir (que siempre lo habrá)
hay que actuar para subsanarlo. La gran importancia de este ciclo sencillo radica en
que se utiliza mucho en la normativa internacional de ISO y de otras instituciones
como la forma de implantar una actividad de mejora continua de cualquier aspecto
en cualquier organización. En la figura 4.2 se muestra este ciclo aplicado a la ges-
tión del servicio de TI.
P
Planificar: planificar la
implementación y la entrega
de la gestión del servicio.
Plan
Planificar
D A
Hacer: implementar el plan
Do Act Actuar: mejorar la eficacia y
de gestión del servicio. Hacer Actuar la eficiencia de la entrega
y la gestión de los servicios.
Check
Verificar
C
Verificar: monitorizar, medir
y revisar que los objetivos y
el plan de gestión del servicio
se están alcanzando.
Figura 4.2. Ciclo PDCA aplicado a la implantación del sistema de gestión de TI
El concepto original del ciclo PDCA fue desarrollado por Walter Shewhart, estadís-
tico pionero en el desarrollo de procesos de control estadístico en los Laborarios Bell
de EEUU durante la década de 1930. El ciclo de Shewhart fue adoptado y promo-
cionado posteriormente por un discípulo suyo W. Edwards Deming en la década de
1950, difundiéndose como ciclo o rueda de Deming, quien propuso que los procesos
se deben analizar y medir para identificar las causas de las variaciones que originan
que los productos se desvíen de los requisitos de los clientes. Deming recomienda
que los procesos de negocio deben estar en un bucle realimentado de mejora conti-
nua para poder identificar y cambiar las partes del proceso que necesitan mejora.
Unos años después, en su carrera profesional, Deming modifica el concepto origi-
nal de PDCA, cambiando “check” por “study”, pues según él, “estudiar” describe
mejor la intención inicial, apareciendo el nuevo ciclo Plan-Do-Study-Act (PDSA),
que ha tenido escasa aceptación.
Posteriormente la metodología de mejora continua Seis Sigma define un ciclo de
cinco etapas: Define-Measure-Analyze-Improve-Control (DMAIC) basado en el ciclo
de Deming.
Otros autores proponen anteponer al PDCA una etapa de análisis y de decisión.
Para ello, utilizan la metodología FOCUS (Find-Organize-Clarify-Understand-Start);
creándose un ciclo de nueve etapas denominado: FOCUS-PDCA.
PDCA
ITIL v2, en su libro Planning to Implement Service Management, propone para la

implantación de ITIL un ciclo de seis etapas derivado del PDCA pero que no
encaja exactamente con él. Las etapas de implementación de la gestión del servicio
en ITIL expresadas en modo de pregunta son:
1. ¿Cuál es la visión?: en la que se determinan los objetivos de negocio a alto nivel.
2. ¿Dónde estamos ahora?: realiza una evaluación o assessment de la situación
actual.
3. ¿Dónde queremos estar?: fija unos objetivos medibles.
4. ¿Cómo hacemos para llegar?: que establece el plan de acción de implanta-
ción o mejora de los procesos.
5. ¿Cómo comprobamos que hemos alcanzado los objetivos?: comprobación
de los resultados mediante métricas.
6. ¿Cómo mantenemos lo alcanzado?: en la que se consolidan los logros alcan-
zados previamente.
En la figura 4.3 se muestran estas 6 etapas en las que ITIL v2 estructura la activi-
dad de implementación.
¿Cuál es la visión?
¿Dónde estamos
ahora?
¿Cómo mantenemos ¿Dónde queremos

lo alcanzado? estar?
¿Cómo hacemos
para llegar?
¿Cómo comprobamos
que hemos alcanzado
los objetivos?
Fuente: Libro ITIL Planning to Implement Service Management publicado por OGC.
Figura 4.3. Ciclo de implantación de ITIL de 6 etapas,

propuesto en su libro Planning to Implement Service Management
Como se aprecia, la interpretación del ciclo de Deming no es tan uniforme como

parece a primera vista, pues hay varias formas de interpretar el objetivo de cada una
de estas etapas del ciclo:
a) Siguiendo estrictamente las directrices de Deming, después de la planifica-
ción viene una fase piloto o de test a corta escala del cambio, que se corres-
ponde con la fase de realizar (Do). La fase Check realizaría la comprobación
de que el piloto arroja los resultados esperados, para después proceder a su
implantación en la etapa act. Esta interpretación difiere a la adoptada por la
normativa internacional.
b) Otra interpretación del ciclo de mejora continua PDCA es la siguiente. se
planifica el cambio (Plan), se ejecuta el cambio (Do), se comprueba su
correcto funcionamiento, se identifican acciones de mejora (Check) y se eje-
cutan las acciones correctivas del cambio (Act). Además, en la etapa Act se
identifican y deciden las nuevas mejoras que se deberían llevar a cabo, que
se ejecutarían con otro nuevo ciclo PDCA. En esta interpretación las fases
Check y Act, además de comprobar los logros alcanzados, proporcionan las
entradas a la nueva fase de planificación.
c) En las Normas ISO/IEC 20000, la interpretación realizada del ciclo de
Deming es más parecida al punto anterior, aunque de la lectura de las nor-
mas se aprecia que en la fase Act se incluye el proceso de mejora continua.
Por tanto, en el texto de las normas no se deduce que se deba iniciar un
nuevo ciclo PDCA de mejora, sino que, es la propia fase de Act la que acoge
la mejora continua de la implantación realizada.
En este libro se adopta la interpretación del ciclo de Deming realizada en el punto

b anterior, con un ciclo nuevo de PDCA para cada etapa iniciada de mejora conti-
nua, en el que las fases Check y Act preparan además las actividades que se deberán
planificar en la fase Plan. Así, la primera vez se empezaría por la fase Check. En la
figura 4.4 se muestra este planteamiento.
PDCA es una espiral o proceso repetitivo de implantación de mejoras, suele estar
asociado a programas de mejora de la calidad. Se utiliza mucho en la normativa
internacional. Introduce el ciclo de mejora continua, pues una vez finalizadas las
mejoras, vuelve a empezar con otras nuevas.
En el caso de las Normas ISO/IEC 20000, el ciclo PDCA se utiliza para la imple-
mentación de lo establecido en el sistema de gestión de TI (SGSTI). Al igual que
las máquinas apisonadoras convierten un camino irregular en una autopista de
tránsito rápido, el sistema de gestión de TI permite que las actividades en la orga-
nización fluyan con mayor eficiencia. En la figura 4.5 se muestra una representa-
ción de este símil, que compara el SGSTI con la autopista y el ciclo de implantación
PDCA con la apisonadora que allana el pavimento.
PDCA
Plan
Planificar
Do Act
Ciclo PDCA Hacer Actuar
Fase inicial de evaluación
habitual
y selección de acciones Check
Verificar
C A P D C A
Verificar: Actuar: Planificar: Hacer: Verificar: Actuar:
realizar un identificar planificar la implementar monitorizar, medir mejorar la eficacia
análisis o las acciones implementación el plan de y revisar que los y la eficiencia
evaluación que se deben y la entrega de gestión del objetivos y el plan de la entrega
inicial de la realizar. la gestión servicio. de gestión del y la gestión de
organización del servicio. servicio se están los servicios.
de TI alcanzando.
Figura 4.4. Inicio habitual en TI del ciclo PDCA por una fase inicial de Check y Act
Figura 4.5. El sistema de gestión de TI se implementa con un ciclo PDCA

para alcanzar la excelencia objetivo
UNE-ISO/IEC 20000-1
Nota: La metodología conocida como Planificar-Hacer-Verificar-Actuar (PDCA, del inglés Plan-Do-

Check-Act) puede aplicarse a todos los procesos. La metodología PDCA puede describirse del
modo siguiente:
a) Planificar: Establecer los objetivos y los procesos necesarios para proporcio-

nar resultados de acuerdo con las necesidades del cliente y con las políticas
de la empresa.
b) Hacer: Implementar los procesos.
c) Verificar: Monitorizar y medir los procesos y los servicios contrastándolos con
las políticas, los objetivos y los requisitos, e informar sobre los resultados.
d) Actuar: Emprender las acciones necesarias para mejorar continuamente el
rendimiento y comportamiento del proceso.
La Norma ISO/IEC 20000-1 presenta un esquema del PDCA como motor para la
implementación y mejora de la gestión del servicio. En la figura 4.6, en la parte
izquierda se muestran las entradas a tener en cuenta en la gestión del servicio (requi-
sitos del negocio, requisitos del cliente, solicitudes de servicios nuevos o modifica-
ciones, interfaces con otros procesos, el centro de servicio al usuario, otros grupos o
áreas, etc.). En la parte derecha se muestran las salidas de la actividad de gestión del
servicio (entrega de resultados al negocio, satisfacción de las áreas cliente, los servi-
cios nuevos o renovados disponibles, satisfacción del equipo de TI, etc.). En la parte
central se sitúa la propia gestión de TI, destacándose la necesaria implicación de la
dirección y el motor PDCA para implantar y evolucionar la gestión de TI.
Procesos, herramientas y personas son los ejes de la

implementación
El apartado 4 de las Norma ISO/IEC 20000-1 especifica mientras que la Norma
ISO/IEC 20000-2 recomienda y detalla los temas que se deben tener en cuenta
para la implantación de estas normas en el proveedor de TI. Como se ha visto en el
capítulo 3 de este libro, la implantación de ISO/IEC 20000 se realiza siempre a tra-
vés del sistema de gestión (SGSTI). Es decir, el capítulo 4 recomienda una disci-
plina de trabajo a tener en cuenta para la implantación del SGSTI específico del
proveedor de TI.
Las claves para alcanzar el éxito en una implementación de la gestión de los servi-
cios de TI es tener siempre en cuenta las tres áreas básicas necesarias para el cambio
PDCA
Fuente: UNE-ISO/IEC 20000.
Figura 4.6. La metodología planificar-hacer-verificar-actuar

para los procesos de gestión del servicio
cultural y organizacional: los procesos, las herramientas que los soportan y las per-
sonas. Áreas que, aunque no resultan nuevas en absoluto, no por ello dejan de ser
importantes para estructurar las actividades que se deben realizar. En la figura 4.7
se muestran estas tres áreas alrededor del SGSTI y del ciclo PDCA utilizado para
implementarlo y mejorarlo.
Los procesos marcan las formas de hacer

La definición de nuevas formas de hacer más eficaces, estructurando los trabajos pri-
mero en procesos, estos en subprocesos, en actividades y en procedimientos detalla-
dos, formará parte del conocimiento y cultura de la empresa y se incorporará con
rigor al sistema de gestión (SGSTI). La planificación de la definición de los proce-
sos se realiza en la fase plan y su propia definición se realiza en la fase do. Gran parte
del texto de las Normas ISO/IEC 20000, de los libros ITIL y también el resto de
este libro, están dedicados a especificar y explicar los procesos y las actividades de TI
con gran cantidad de detalles, por lo que no es necesario tratarlo en este capítulo.
Figura 4.7. Las 3 áreas que se deben considerar siempre

para la implantación con éxito de ISO/IEC 20000
La experiencia muestra que estos marcos de mejores prácticas utilizan una visión
bastante homogénea de los procesos y de su contenido, por lo que las diferencias
en la definición de los mismos son pequeñas. Es en los detalles de quién y con qué
se realizan (contenidas en los procedimientos) cuando empiezan a aparecer diferen-
cias entre las organizaciones. Por este motivo se recomienda realizar con rapidez la
definición de procesos y procedimientos, y también contar con el apoyo de una
consultora externa para ello.
La definición de los procesos es una actividad importante en la implantación y, ade-
más, se suele concluir con bastante éxito. Pero hay que recordar que no es la única
faceta: los procesos hay que implantarlos para que el personal trabaje de acuerdo a
ellos; el apoyo de las herramientas de gestión es esencial para dar eficiencia y con-
ducir el trabajo diario; y el cambio cultural de la organización es el factor más difí-
cil de llevar a cabo.
Las herramientas son necesarias para la productividad y

el control
Las Normas ISO/IEC 20000 no establecen ningún requisito ni recomendación
sobre las herramientas de soporte a la gestión de TI y la actividad de los procesos.
Pero, en las instalaciones medianas, y especialmente en las grandes, las herramientas
PDCA
de gestión de TI son esenciales para proporcionar la agilidad necesaria en la organi-

zación, para garantizar que se siguen las formas de hacer definidas, y para almace-
nar y retener el conocimiento. Además, las herramientas permiten el seguimiento
de los procesos, su medición y su mejora.
Las herramientas son uno de los factores críticos de éxito en la implantación de la
norma. Pero las herramientas tienen un coste nada despreciable: en licencias (aun-
que hay algunas gratuitas), en plataforma, en parametrización, en soporte, en for-
mación y en su evolución. Dependiendo del tamaño del proveedor de TI, de la
diversidad de los servicios y del volumen de su actividad, variará la complejidad de
las herramientas. La selección de las herramientas vendrá marcada por los requisi-
tos que impongan los procesos ya definidos. También hay que considerar el apro-
vechamiento de las que están en uso (siempre que cumplan las exigencias de los
procesos).
La selección y compra de un conjunto de herramientas de gestión no es una labor
trivial y, con frecuencia constituye un proyecto en sí mismo. Hay que establecer: el
ámbito que se debe cubrir, una extensa lista de requisitos que se deben exigir a las
herramientas, analizar la oferta del mercado, etc. También, la propia implantación
de las herramientas en sí, constituye uno o varios proyectos, dependiendo del
tamaño de la instalación y la diversidad de productos seleccionados.
Hay un primer grupo de herramientas que posibilitan la actividad de implantación
de las normas, por lo que deben ser las primeras que se seleccionen e implementen,
por ejemplo:
• El soporte documental del sistema de gestión. Es recomendable disponer
de un gestor documental con control de versiones y acceso web. Aunque en
los inicios, cualquier herramienta colaborativa con interfaz web de la
empresa podrá demorar la inversión en el gestor documental, e incluso, con
un sistema de archivos organizado y controlado puede ser suficiente en
estos inicios.
• La herramienta de diseño de procesos. En el mercado hay varias herramien-
tas de diseño de procesos que se pueden utilizar a estos fines. Hay que deter-
minar que información irá volcada en la herramienta de procesos y cual se
mantendrá externamente en archivos de texto. En cualquier caso, TI debería
utilizar la herramienta y metodologías utilizadas en la empresa para definir
sus procesos de negocio, y no “trabajar por su cuenta”; situación bastante
frecuente. Si la empresa no tiene una sólida implantación de la cultura de
calidad y procesos, es habitual que se empiece con una solución de diagra-
mación de flujos ofimática (como Microsoft Visio o Microsoft PowerPoint)
y la descripción de los procesos en texto (Microsoft Word). Este escenario
no se recomienda, pues cualquier evolución obligará a revisar las referencias

cruzadas en los textos y redibujar todos los gráficos.
• Una herramienta de gestión de proyectos que implemente la metodología
que se vaya a seguir. La implementación de la gestión del servicio es com-
pleja, lleva mucho tiempo y puede estar formada por varios proyectos que
transcurrirán en paralelo. Por ello, se debe contar desde el principio con una
herramienta que permita realizar una planificación tanto de alto nivel, como
de detalle. Siempre que sean adecuadas, se recomienda utilizar las herramien-
tas y metodologías existentes en la empresa, pues la implementación de las
normas debe apoyarse y aliarse con toda la organización. En un escenario
básico para la gestión de proyectos la herramienta ofimática Microsoft
Project puede ser válida. En relación a las metodologías, el “mundo ITIL”
recomienda el uso de Prince2. También PMBOK está muy extendido para
proyectos de desarrollo de software.
• Un cuaderno de bitácora. En él se registrarán día a día las acciones que se
están ejecutando y las actas de las reuniones. Este diario podrá acabar con-
virtiéndose en un blog interno de soporte a la comunicación del proyecto.
En la estrategia de implantación se definirán los procesos a implantar, normal-

mente en una aproximación por fases. Lógicamente, según sea el orden de implan-
tación de los procesos, se deberán incorporar las herramientas que los soporten,
por lo que las herramientas se irán añadiendo paulatinamente, acompañando a la
implantación de los procesos, pero siempre dentro de una estrategia previamente
definida.
A continuación se presenta una relación de herramientas de gestión de TI típica-
mente utilizadas en las empresas más avanzadas, cada organización deberá adaptar
esta relación a sus características particulares:
• Herramienta para la gestión de contactos en el centro de atención del usuario.
• Herramienta para la gestión de incidentes o herramienta de ticketing.
• Herramienta para el autorregistro web de incidentes y peticiones de usuarios.
• Herramienta para la autorresolución de incidentes por los usuarios.
• Herramienta para la gestión de la configuración, incluyendo la base de datos
de configuración (CMDB).
• Herramienta para a gestión de inventarios y activos.
• Herramientas para el autodescubrimiento de activos: de ordenadores perso-
nales, de elementos de red, de servidores, de usuarios, etc.
PDCA
• Herramienta para la gestión del cambio.

• Soporte a la biblioteca definitiva de software (DSL).
• Herramienta para la gestión de nivel de servicio. Herramientas para una
visión dinámica del estado de cada servicio y de sus componentes.
• Portal para la publicación de informes web, estáticos o dinámicos.
• Soporte a la base de datos de la capacidad (CDB).
• Herramienta para el control y registro de costes.
• Herramienta para el análisis de tendencias.
• Gestor documental del sistema de gestión SGSTI.
• Herramienta de diseño de procesos.
• Herramienta de gestión de proyectos.
• Cuaderno de bitácora y un boletín de comunicación.
• Herramienta de gestión de perfiles profesionales y RRHH de TI.
• Plataforma de monitorización y una consola central de eventos.
Además, también será necesario un conjunto de herramientas “técnicas” de admi-

nistración y gestión de: servidores, bases de datos, discos de almacenamiento, equi-
pos de comunicaciones, planificación de trabajos batch, seguridad, etc.
Con la intención de simplificar para los que se inician en el camino (y siempre pen-
sando en las instalaciones medianas o grandes), el conjunto mínimo de herramien-
tas que un proveedor de TI tipo debería tener en las etapas iniciales sería: la ges-
tión documental para alojar el SGSTI, la herramienta para la gestión de incidentes,
la CMDB, la DSL y un portal para la publicación web de informes. El resto de las
necesidades de herramientas se podría cubrir inicialmente con soluciones ya exis-
tentes en la empresa o soluciones provisionales basadas en herramientas ofimáticas.
En la figura 4.8 se muestra un conjunto básico de herramientas señalando los pro-
cesos que cubren sobre el esquema de ISO/IEC 20000.
Si analizamos el desglose de los costes de un proyecto de implantación de herra-
mientas, se aprecia que, normalmente, la partida de licencias software suele suponer
el 30% del presupuesto del proyecto. El 70% restante se repartiría entre los servi-
cios de implantación, la formación, cambio cultural y el hardware de los servidores.
También hay que considerar, para los presupuestos futuros, el coste del manteni-
miento evolutivo y correctivo de las mismas, así como, el coste de operación y de
mantenimiento.
Figura 4.8. Herramientas mínimas e imprescindibles

en la gestión del servicio y los procesos a los que dan soporte
Cuidar al personal de TI es clave para el éxito

No hay que olvidar que una excelente definición de procesos que engranen todas
las actividades a la perfección no es suficiente. Ni siquiera con las mejores herra-
mientas de soporte, pues gran parte del trabajo requiere de la intervención de las
personas que forman el equipo de TI. Por lo que el frecuentemente olvidado factor
humano resulta ser clave para el éxito de la implantación y, por ende, clave para la
supervivencia de la empresa.
No hay un directivo en el elenco de TI que no predique y derroche halagos sobre la
importancia de las personas que forman su equipo de trabajo, pero con frecuencia
todo se queda solamente en palabras. Todo directivo que se precie deberá apostar
claramente por el factor humano, con acciones tangibles y concretas ya que para el
éxito de la implementación de las nuevas formas de trabajo las palabras no bastan.
El personal de TI, muy machacado por la presión diaria, no se deja influir fácil-
mente por declaraciones de principios relativas a la importancia de las personas. Lo
que necesita son hechos visibles que les demuestren que la alta dirección apuesta de
PDCA
verdad por el cambio y que ellos son importantes para conseguirlo. Sin cumplir
este requisito el fracaso está garantizado.
La importancia de las personas en este camino de transformación se debe manifes-
tar nítidamente en:
• Planes paulatinos, constantes e intensivos de formación sobre las nuevas for-
mas de trabajo y las nuevas herramientas de gestión.
• Entrenamiento individual en las funciones de su puesto, hasta que cada uno
llegue a desempeñarlas a la perfección.
• Comunicación, ánimo y estímulo constante. Mediante conferencias, reunio-
nes, boletines internos, etc. Transmitiendo tranquilidad ante la incertidum-
bre del cambio y entusiasmo.
• Motivación permanente a los que se implican y una gestión pertinaz de quie-
nes se muestran reticentes al cambio.
• Evolución organizativa ágil. Los nuevos roles necesarios se deben definir y
nombrar con rapidez.
• Autoridad y disciplina. Es necesario mantener el principio de autoridad, pues
el servicio de TI no es un juguete tecnológico, y sí es o será la pieza esencial
para la supervivencia de la empresa.
• Foco en el dominio de la tecnología. No se debe olvidar la necesidad del
dominio absoluto de la tecnología, sin el cual, todo esfuerzo de establecer
procedimientos y organizar será en vano. Así, por muy detallados que se ten-
gan los procedimientos, por muy alineados que se esté con el negocio, si los
programadores no saben construir código de calidad o si el técnico de
soporte al intentar resolver una incidencia destroza el equipo por desconoci-
miento técnico, no hay transformación posible.
Fase preliminar a la implementación: evaluación o

assessment inicial
Cuando el proveedor de TI se sitúa por primera vez ante el dilema de cómo
abordar la implementación, en las Normas ISO/IEC 20000 aprecia la falta de
una etapa previa que analice la situación actual de la organización de TI, y deter-
mine las acciones y permita establecer fases. En implantaciones de estas normas
es frecuente y recomendado empezar por una evaluación de la situación actual de
partida (o assessment), en el mercado hay varios modelos aplicados específicamente
a ISO/IEC 20000 o a ITIL. El informe resultante de la evaluación debería tratar

los aspectos siguientes:
• La evaluación debería comenzar con la descripción de la problemática prin-
cipal actual de la organización que se quiere resolver, si es que estuviera iden-
tificada.
• Una descripción de la organización: misión, servicios, infraestructuras, tec-
nología, personal, estrategia de contratación, contratos con suministradores,
volúmenes de actividad (número de incidentes, solicitudes, cambios, etc.),
herramientas de gestión y técnicas utilizadas, tendencias del negocio, tenden-
cias tecnológicas, etc.
• Un análisis de la madurez inicial de la actividad de la organización, siguiendo
la estructura de procesos de la norma. Este análisis se suele realizar mediante
un cuestionario que suelen contener entre 8 y 20 preguntas por proceso,
según el grado de profundidad que se quiera alcanzar. El cuestionario se cen-
tra tanto en la identificación de prácticas o actividades frente al marco de refe-
rencia, como en el grado de formalización de los procesos en la organización.
• Un análisis de ratios o indicadores generales de la organización y su compa-
ración con el mercado (benchmarking).
• Una matriz de debilidades y fortalezas, que en ocasiones se extiende a la
matriz de debilidades-amenazas-fortalezas-oportunidades (DAFO).
• Las conclusiones, con las recomendaciones y acciones a emprender, estable-
ciendo fases para ellas.
La evaluación inicial se puede realizar de forma interna o contando con el apoyo de

una consultora externa. Las consultoras tienen sus propios modelos de evaluación,
pero también se pueden encontrar otros en el mercado (así itSMF-UK tiene uno vin-
culado a ITIL, itSMF-España dispone de otro similar, etc.). El resultado de la evalua-
ción se suele representar en formato de gráfico circular, tipo “araña” o de Kiviat, en el
que se representa en una silueta la madurez obtenida proceso a proceso. En el gráfico
de la figura 4.9 se ilustran a modo de ejemplo los resultados de una evaluación.
La evaluación de los procesos, que se suele medir en una escala de cinco “niveles de
madurez” de 1 a 5, normalmente se inspira en el modelo utilizado por CMMI, (en
el ámbito de estas normas todavía no hay un modelo consensuado o estandari-
zado). A continuación se detallan los niveles definidos en ITIL v2 (consúltese Plan-
ning to Implement Service Management. Anexo J “Process Maturity Framework”):
1: Inicial. Las organizaciones en este nivel no disponen de un entorno estable.
Aunque se utilicen técnicas correctas, los esfuerzos se ven minados por falta
PDCA
SGSTI
Entrega 5 PDCA
Cambio 4 Herramientas
3
Creación
Configuración
2 servicios
1
Nivel de
Problema
servicio
0
Incidente Informes
Suministradores Contin. y
dispon.
Relaciones
Presupuestar
negocio
Seguridad Capacidad
Figura 4.9. Ejemplo de resultados en un gráfico tipo “araña” o de Kiviat

de una evaluación de madurez de procesos ISO/IEC 20000
de planificación. El éxito se basa la mayoría de las veces en el esfuerzo perso-

nal aunque, a menudo, se producen fracasos y casi siempre retrasos y sobre-
costes. El resultado es impredecible.
2: Repetible. En este nivel las organizaciones disponen de unas prácticas insti-
tucionalizadas de gestión de proyectos, existen unas métricas básicas y un
razonable seguimiento de la calidad. La relación con suministradores y clien-
tes está gestionada sistemáticamente.
3: Definido. Además de una buena gestión de proyectos, a este nivel las orga-
nizaciones disponen de correctos procedimientos de coordinación entre gru-
pos, formación del personal, técnicas de procesos más detalladas y un nivel
más avanzado de métricas en los procesos.
4: Gestionado. Se caracteriza porque las organizaciones disponen de un con-

junto de métricas significativas de calidad y productividad que se utilizan de
modo sistemático para la toma de decisiones y la gestión de riesgos. Los ser-
vicios resultantes son de calidad.
5: Optimizado. La organización completa está volcada en la mejora continua
de los procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de
innovación.
El comportamiento de las organizaciones sigue patrones

similares
La experiencia demuestra que las organizaciones, a la hora de abordar la implemen-
tación de la gestión del servicio de TI, siguen patrones de comportamiento bas-
tante similares según sea la situación y motivación del proveedor que le impulsa a
adentrarse en la transformación hacia procesos eficientes. Gracias a este ejercicio de
síntesis, conociendo cuál es la motivación inicial que impulsa la adopción, se puede
predecir cuál será el patrón de comportamiento de la organización a lo largo del
proceso de implementación.
Los patrones de comportamiento de las organizaciones ante la implementación de
la gestión del servicio se han dividido en 5 perfiles:
1. Saturados. Por la actividad diaria que prácticamente no tienen capacidad de
moverse debido a la saturación.
2. Económicos. Organizaciones en una situación de fuerte contención econó-
mica que fuerza a la utilización de los recursos internos y al uso de las herra-
mientas existentes.
3. Obligados. La obtención del certificado de conformidad con las normas es
el principal impulsor del proceso, limitando las oportunidades de mejora.
4. Condicionados. Normalmente por movimientos derivados de consolidacio-
nes organizativas o externalizaciones parciales, hacen que sea necesario uni-
formizar las formas de hacer. Por suerte, en estos escenarios dentro de los
planes y presupuestos de la consolidación caben las partidas para la transfor-
mación de la organización, con lo que los resultados llegan a ser similares a
los visionarios.
5. Visionarios. La alta dirección de TI ve con una nitidez meridiana la necesi-
dad de transformación, liderando todo el proceso.
PDCA
La figura 4.10 muestra el detalle de estos 5 patrones de comportamiento.
– +
SATURADOS ECONÓMICOS OBLIGADOS CONDICIONADOS VISIONARIOS
(Por actividad diaria) (En reducción (Por necesidad (Por consolidaciones o (Negocios en alza)
de costes) de certificado) por outsourcing)
Patrones de comportamiento durante la implementación de la gestión del servicio
• Formación reducida. • Charlas introductorias. • Foco en “aprobar el • Formación global: • Formación global:
• Creen en ITIL pero • Formación examen” que supone amplia. extensiva.
“no practican”. especializada: puntual. la obtención de la • Formación • Formación
certificación. especializada: amplia. especializada:
• Desarrollo de • Desarrollo de
proyectos puntuales proyectos tácticos. • Una o dos personas • Desarrollo de proyectos abundante.
y por necesidad encargadas de estratégicos y • Desarrollo de
• Equipos de proyecto preparar un sistema
operativa formado por personal “completos”. proyectos estratégicos
(por ejemplo, de documentación (y tácticos alineados
interno. que justifique el • Equipos de trabajo con
catálogo de personal interno y fuerte con la estrategia).
servicios, etc.). • Reutilización de cumplimiento de
herramientas existentes. las normas. apoyo de especialistas • Equipos de trabajo
externos. con personal interno
• Compra herramientas • Foco en los papeles y fuerte apoyo de
de forma puntual. y en la formalización • Foco en normalización
integrada y herramientas especialistas externos.
documental.
que lo soporten. • Foco en normalización
• Poco interés por mejorar. e integración de
• Mejoras de “rebote”. procesos y las
• Cambios puntuales. herramientas que
lo soporten.
• Charlas introductorias.
• Formación especializada
puntual.
Figura 4.10. La situación de partida permite prever el comportamiento

en la implementación
Planificación de la gestión del servicio (Planificar)
UNE-ISO/IEC 20000-1
Objetivo: Planificar la implementación y la provisión de la gestión del servicio.

Se debe planificar la gestión del servicio. Como mínimo, el plan debe definir lo
siguiente:
a) el alcance de la gestión del servicio del proveedor del servicio;
b) los objetivos y los requisitos que se tienen que alcanzar por la gestión del servicio;
c) los procesos que se van a ejecutar;
d) el marco de los roles y responsabilidades de la dirección, incluyendo al direc-
tivo de alto nivel responsable directo, al propietario del proceso, a la dirección
de la gestión y a la dirección de los suministradores;
e) las interfaces entre los procesos de gestión del servicio y el modo en que
tienen que coordinarse las actividades;
f) el enfoque que hay que dar a la identificación, la evaluación y la gestión de
actividades y de los riesgos para la consecución de los objetivos definidos;
g) el enfoque para la relación con proyectos que estén creando o modificando
los servicios;
h) los recursos, el equipamiento y los presupuestos necesarios para alcanzar los
objetivos definidos;
i) las herramientas adecuadas para dar soporte a los procesos; y
j) cómo se va gestionar, auditar y mejorar la calidad del servicio.
Deben estar claramente definidas tanto la orientación de la gestión como las res-
ponsabilidades documentadas para revisar, autorizar, comunicar, implementar y
mantener los planes.
Cualquier plan específico de un proceso que se elabore debe ser compatible con
este plan de gestión del servicio.
Además, ISO/IEC 20000-2 añade dos aspectos más que se deberían considerar en
la planificación:
UNE-ISO/IEC 20000-2
g) una planificación de los recursos h) el enfoque para la modificación
expresada en términos de las fechas del plan y de los servicios defini-
en las que deberían estar disponi- dos por el plan;
bles las fuentes de financiación, las
habilidades y los recursos;
PDCA
El plan de implantación debe contemplar todos los aspectos relativos a los tres blo-
ques principales: los procesos, las herramientas de gestión necesarias y las perso-
nas. En la figura 4.11 se aprecia un ejemplo de las actividades que se deben con-
templar en un plan de implantación de estas normas.
• Definición de los primeros estándares:

Catálogo de servicios y diseño CMDB.
• Definición de los procesos.
PRELIMINAR PROCESOS
• Definición de los procedimientos.
• Definición de los roles y puestos.
• Formación a líderes. • Definición de indicadores e informes.
• Creación equipo
implementación.
• Evaluación o assessment. • Requisitos herramientas.
• Objetivos. • Selección y compra SW/HW.

HERRAMIENTAS
• Plan implementación. • Parametrización herramientas.
DE GESTIÓN TI
• Presentaciones internas. • Implantación herramientas.
• Comunicación inicial. • Carga de datos.
• Formación de profesionales.
• Plan de comunicación.
• Cambio organizativo.
PERSONAS
• Entrenamiento personal.
• Despliegue de herramientas.
• Cambio de formas trabajo.
Figura 4.11. Toda implementación debe contemplar los tres aspectos

fundamentales: los procesos, las herramientas y las personas
En la figura 4.12 se muestra una aproximación sencilla en 5 pasos a la implementa-

ción de la gestión del servicio, con el fin de demostrar que es posible iniciar el
camino sin excesiva complejidad. En este ejemplo, la implementación se inicia con
una evaluación (interna o externa) de madurez, para pasar a constituir un pequeño
equipo de trabajo que se responsabilizará de todo el proceso. El tercer paso sería
formalizar el plan de implementación, para iniciar un proceso de formación y certi-
ficación de los profesionales de TI que acompañará prácticamente a todo el pro-
ceso de realización.
1.o Realizar una evaluación de la madurez inicial
SGSTI
Entrega 5 PDCA
Cambio 4 Herramientas
3
Creación
2.o Crear un equipo de trabajo

Configuración
2 servicios
1
Nivel de
Problema
servicio
0
Incidente Informes
Suministradores Contin. y
dispon.
Relaciones
Presupuestar
negocio
Seguridad Capacidad
3.o Definir la estrategia de implementación

Mandato de la dirección
Definir el plan de implantación
4.o Formación y certificación de profesio- Otras etapas de PDCA: ejecución del plan
nales clave en ITIL e ISO/IEC 20000 de implementación, comprobación y mejora
Figura 4.12. Ejemplo de una aproximación sencilla a la implementación
Alcance de la gestión del servicio
UNE-ISO/IEC 20000-2
El alcance de la gestión del servicio se La dirección debería definir el alcance

debería definir como parte del plan de como parte de sus responsabilidades de
gestión del servicio. Por ejemplo, puede gestión (y como parte del plan de ges-
definirse según: tión del servicio). Luego se debería com-
probar si el alcance resulta adecuado
a) la organización;
para la Norma ISO/IEC 20000-1.
b) la ubicación;
Nota: La planificación de los cambios operativos
c) el servicio. se describe en el apartado 9.2.
PDCA
ISO/IEC 20000 requiere de un compromiso expreso de la dirección de la empresa.

Éste es un requisito general que se aplica en toda la parte 1 de estas normas, y muy
especialmente en los apartados que necesitan de un mayor empuje como es la
implementación del SGSTI.
Enfoques de la planificación
UNE-ISO/IEC 20000-2
Se pueden utilizar varios planes de ges- Un plan de gestión del servicio debería
tión del servicio en lugar de un plan o incluir:
programa de gran magnitud. En este a) la implementación de la gestión
caso, los procesos subyacentes a la ges- del servicio (o de parte de la ges-
tión del servicio deberían ser coherentes tión del servicio);
entre ellos. También se debería poder
b) la entrega de los procesos de la
demostrar cómo se gestiona cada
gestión del servicio;
requisito de planificación vinculándolo
a sus correspondientes funciones, res- c) los cambios de los procesos de la
ponsabilidades y procedimientos. gestión del servicio;
La planificación de la gestión del servi- d) las mejoras de los procesos de la
cio debería formar parte del proceso gestión del servicio;
para convertir las necesidades de los e) los nuevos servicios (hasta el punto
clientes y las intenciones de los directi- que afecten a los procesos inclui-
vos en servicios y para proporcionar dos en el alcance acordado de la
una guía para dirigir el progreso. gestión del servicio).
Orden de implementación de los procesos

En el momento de seleccionar los procesos que se van a implementar se plantean
varias tácticas posibles. Se presentan dos aproximaciones generales:
• Implantar los procesos uno a uno para todos los servicios y toda la organiza-
ción de TI. Permite ir extendiendo las mejoras paulatinamente de una forma
más uniforme.
• Seleccionar uno o varios servicios y, sobre este núcleo más reducido, implantar
todos los procesos. Esta es la implantación es más rápida y permite aprender
de los errores cometidos, pero plantea en TI una dicotomía, pues las mismas
personas tendrán que trabajar de una forma o de otra según del servicio de
que se trate. Debemos destacar que este segundo caso es el más eficaz para la
obtención de un certificado.
En la figura 4.13 se muestra la implementación del sistema de gestión en varias eta-

pas que pueden corresponder a la implementación progresiva de procesos o a la
incorporación paulatina de servicios por fases al SGSTI.
Figura 4.13. La transformación de la organización se realiza

normalmente en etapas paulatinas
Es conveniente comentar diversas estrategias de planificación de la implantación

para seleccionar los procesos por los que empezar la implementación, según sea la
situación o problemática de partida de cada organización. Hay que tener en cuenta
que todos los procesos están relacionados, por lo que el beneficio completo no se
PDCA
consigue hasta que no estén todos ellos implantados. Como las combinaciones son
muchas, a continuación se presentan las más frecuentes:
• Escenario 1: Inestabilidad. Una organización con inestabilidad y con con-
tinuos cortes del servicio estará sumida en una crisis permanente restaurando
los servicios. En esta situación, lo primero que hay que hacer es poner foco
inmediato en controlar la situación. Para ello será necesario trabajar con la
gestión del incidente para minimizar los tiempos de no disponibilidad. De
forma casi paralela, parece razonable implementar también la gestión del
cambio, que pone orden en todo paso al entorno productivo y reduce el
número de incidentes que se producen derivados de los cambios. Además,
será conveniente iniciar la gestión del problema, para eliminar los fallos y
defectos ocultos. También se debería abordar soluciones de monitorización
para tener un mejor control del entorno productivo.
• Escenario 2: Garantizar. Es este caso, la organización de TI necesita dar
garantías al negocio de que las pérdidas de información y del servicio son
mínimas. Lógicamente, es una situación más avanzada que el escenario 1 de
crisis, aunque no se debe poner en riesgo el negocio por que TI no pueda
recuperar los datos o los sistemas. El foco se debe poner en los procesos que
garantizan que los servicios se puedan restaurar en cualquier situación, bien
sea por fallos locales o por el impacto de desastres mayores. Antes de comen-
zar con los procesos ISO/IEC 20000, habrá que revisar o implantar una
solución sólida de copias de seguridad (backup). Después, deberá centrarse
en el registro de las versiones de las aplicaciones instaladas y de la parametri-
zación realizada. Para ello ser tratará la gestión de la configuración y la ges-
tión de la entrega. Posteriormente, se implementará la gestión de la conti-
nuidad para garantizar la recuperación en caso de desastre.
• Escenario 3: Relaciones. Si el servicio es estable pero la opinión de las
áreas negocio clientes sobre el servicio de TI es mala y las relaciones son
tensas y difíciles, la estrategia debe ser distinta. Hay que ponerse de inme-
diato a regular y mejorar la comunicación, a tranquilizar al negocio y a ges-
tionar las expectativas. En este escenario lo razonable sería comenzar con la
gestión de las relaciones con el negocio y definir un catálogo de servicios
que regule las expectativas sobre TI, para pasar inmediatamente a la defini-
ción de acuerdos de nivel de servicio (SLA) y a implementar la gestión de
nivel de servicio que se encargue de seguir su cumplimiento. La gestión
de informes y su disponibilidad online al negocio mejorará enormemente la
percepción sobre TI.
En la figura 4.14 se muestra un esquema de los escenarios 1 al 3.

Escenario 1 Escenario 2 Escenario 3

¡Inestabilidad! ¡Garantizar! ¡Relaciones!
Copias de Gestión de las

Gestión del
backup relaciones con
incidente
robustas el negocio
Gestión de la
Gestión Catálogo
configuración
del cambio de servicios
CMDB y DSL
Gestión del Gestión de Gestión de nivel

problema la entrega de servicio
Plataforma de Gestión de la Gestión

monitorización continuidad de informes
Figura 4.14. Ejemplos de estrategias de implantación de procesos

según la situación a resolver
Además de los ejemplos anteriores, se pueden dar otras situaciones a partir de las
cuales se decide implementar ISO/IEC 20000:
• Escenario 4: Un problema. Foco en resolver un problema inmediato que
existe en la organización. En este caso, TI no se puede detener a realizar eva-
luaciones sobre la madurez actual. Se deben identificar los principales pro-
blemas acuciantes del proveedor de TI para buscar soluciones inmediatas.
Cada problema tendrá su propia aproximación. El problema puede ser de
índole técnico, organizativo, de motivación, de capacitación, de gestión, etc.
Las Normas ISO/IEC 200000, junto con ITIL y el sentido común, aporta-
rán alguna vía de solución.
• Escenario 5: Foco en los servicios críticos. La empresa tiene claramente
identificados cuáles son sus servicios críticos con gran impacto en la actividad
PDCA
del negocio. En este caso, la estrategia recomendada es implementar el

SGSTI circunscrito inicialmente a este núcleo de servicios críticos, que por
otra parte serán los más cuidados, y con los que se justificarán ante la direc-
ción mejor las inversiones para el inicio de la transformación.
• Escenario 6: Obtener la certificación. El mercado, la legislación o la
dirección exige al proveedor de TI la obtención inmediata de la certifica-
ción ISO/IEC 20000. En esta situación no hay alternativa posible. Para
obtener la certificación será necesario implantar los 14 procesos de estas
normas. Además, se deberá formalizar todo en el sistema de gestión
SGSTI. La única variable en este escenario sería intentar acotar el alcance
de la certificación a los servicios con más repercusión en el mercado o afec-
tados por la legislación, con el fin de agilizar al máximo la obtención del
citado certificado.
• Escenario 7: Crisis económica. Situación marcada por la necesidad de fuer-
tes restricciones presupuestarias, en las que la organización de TI debe aqui-
latar al máximo sus costes recurrentes. En este escenario, TI también es un
excelente instrumento para proponer soluciones que ayuden a la reducción
de los costes operativos de la empresa. Dada la necesidad imperiosa de con-
trol de los costes, será necesario comenzar por el proceso de elaboración de
presupuestos y contabilizar, seguido del proceso de gestión de la capacidad
que permitirá ajustar los recursos sin comprometer el servicio. Las relaciones
con el negocio permitirán a TI proponer nuevas soluciones.
Eventos a considerar
UNE-ISO/IEC 20000-2
El plan de gestión del servicio debería d) los cambios de la legislación;

estar enfocado a los procesos de ges-
e) las modificaciones de normativas
tión del servicio y a los cambios en los
como, por ejemplo, modificaciones
servicios desencadenados por eventos
de las tasas impositivas locales;
como los siguientes:
f) la liberalización o la regulación
a) la mejora del servicio;
de los sectores industriales;
b) los cambios en el servicio;
g) las fusiones y las adquisiciones.
c) la normalización de infraestruc-
turas;
Búsqueda de éxitos rápidos (quick-wins)

En la planificación de la implementación hay que tener en cuenta la búsqueda de
éxitos rápidos, conocidos como quick-wins. Dado que el proceso de transformación
es prolongado, resulta esencial acompañar todo el camino con éxitos rápidos que
infundan moral y confianza en el proyecto, tanto a la dirección, como al resto del
personal.
Un éxito rápido es una actuación sencilla de implementar que aporta resultados
tangibles de forma inmediata. Lo que se percibe como un éxito rápido varía de una
a otra organización. A continuación se enumeran algunos ejemplos posibles:
1. Creación del comité de cambios que de forma inmediata ponga orden en las
implantaciones. Definir un documento de petición de cambio.
2. Mejorar la atención de incidencias centrándose en un sistema crítico.
3. Documentar la configuración de los sistemas críticos.
4. Crear un catálogo de servicios que permita empezar a hablar en términos de
servicio.
5. Resolver algunos de los problemas que generan muchos incidentes.
6. Si no existe, establecer un punto único de contacto para los usuarios con TI.
7. Implementar un formulario web de registro de peticiones e incidentes de
usuario para reducir las llamadas telefónicas al centro de atención al usuario.
8. Añadir a la anterior una página web para la autorresolución por parte del
usuario de las peticiones más frecuentes (por ejemplo, la restauración de con-
traseñas).
9. Consolidar la información de incidentes en una única base de datos.
10. Con el fin de involucrar a todas las partes, definir un ciclo completo para la
creación de nuevos servicios, involucrando al personal de desarrollo y al de
planificación y control.
11. Empezar a publicar métricas semanales de la actividad de TI. Implemen-
tar una monitorización desde el punto de vista del usuario (al efecto exis-
ten soluciones sencillas de navegación que simulan el comportamiento
del usuario). Publicar vía web la monitorización para el acceso de las
áreas cliente.
12. Realización de un informe sobre el estado de TI que permita involucrar la
dirección en el proyecto.
PDCA
13. Establecer acciones de formación para los principales actores en TI. Se

puede optar por un día de introducción a ITIL con ejercicios de simulación,
o directamente impartir cursos de tres días de introducción a ITIL (denomi-
nado Foundation).
Conviene tener en cuenta que los éxitos rápidos hay que publicitarlos en la organi-
zación.
Implementación de la gestión del servicio y provisión de

los servicios (Hacer)
UNE-ISO/IEC 20000-1
Objetivo: Implementar los objetivos y el plan de gestión del servicio.

El proveedor del servicio debe implementar el plan de gestión del servicio para pro-
veer y gestionar los servicios, incluyendo:
a) la asignación de presupuestos y fondos;
b) la asignación de roles y responsabilidades;
c) la documentación y el mantenimiento de políticas, planes, procedimientos y
definiciones para cada proceso o conjunto de procesos;
d) la identificación y la gestión de riesgos para el servicio;
e) la gestión de los equipos de trabajo, por ejemplo, la contratación y el desarrollo
del personal adecuado y la gestión de continuidad del personal;
f) la gestión del equipamiento y el presupuesto;
g) la gestión de los equipos o grupos de personas, incluidos los del centro de ser-
vicio al usuario y los de operaciones;
h) informar del progreso en comparación con los planes; y
i) la coordinación de los procesos de gestión del servicio.
ISO/IEC 20000-1 comienza sus requisitos de la fase de implementación con la

asignación de presupuestos y fondos, así como la asignación de roles y responsabi-
lidades. Estas son las primeras actividades de la fase de realizar.
En el punto c del recuadro anterior de la norma se recoge toda la actividad de

documentación, incluyendo las políticas, los planes, definiciones de los procesos,
los procedimientos, etc. En el capítulo 3 de este libro, relativo al SGSTI, se reflejó
la necesidad de crear un sistema documental, que es esencial para todo el proceso
de implementación.
Los siguientes requisitos son relativos a la gestión necesaria durante todo el pro-
ceso de implementación, comprendiendo riesgos, equipamiento, presupuestos,
equipos o grupos de soporte, etc.
También es esencial la comunicación con toda la organización para mantener infor-
mado tanto a la dirección como al resto del personal de todo el proceso de imple-
mentación.
Por supuesto, todo cambio debe ser coordinado con los procesos de gestión del ser-
vicio que ya existan, o con los que actualmente realicen sus funciones.
Grupo de implementación o de procesos de TI

Como ya se ha visto, en el capítulo 3, se necesita la fuerte implicación de la alta
dirección, la necesidad de un responsable de alto nivel en la organización de TI
denominado “patrocinador” o responsable del SGSTI y, que este responsable debe
contar con personal de apoyo en su labor. Para la etapa de planificación e implanta-
ción de estas normas se debe constituir un equipo de trabajo específico o grupo de
implantación, que estará activo desde las primeras fases de definición hasta concluir
la implantación final.
El grupo de implantación dependerá directamente del “patrocinador” y se debería
situar jerárquicamente en el organigrama como un grupo de apoyo al director de TI
(habitualmente denominado CIO, del inglés: Chief Information Officer). Aunque es
menos recomendable, a veces en grandes organizaciones este equipo depende del
director de explotación, de producción o de operaciones (véase la figura 4.15).
Otras veces, este equipo de procesos de TI está vinculado al ámbito de gobierno o
de planificación y control de TI. En otros casos, los procesos de TI están asociados
con las arquitecturas de TI (de datos, de aplicaciones y de plataformas).
A la hora de definir los procesos, el grupo de implantación debe involucrar a las
personas clave de la organización de TI que conocen el funcionamiento interno y
las actividades que se realizan. También debería trabajar estrechamente con las áreas
de calidad o procesos de la empresa. El equipo de implantación deberá dedicar un
tiempo inicial a preparar el entorno de trabajo y el control de todos los proyectos
que surjan para la implementación del sistema de gestión.
PDCA
UNE-ISO/IEC 20000-2
Nota: Es posible que la persona que sea ade- mentación inicial no sea la apropiada para la
cuada para realizar la planificación y la imple- operación continua.
Con frecuencia, en las implantaciones de la gestión del servicio, el equipo que

implanta no es el mismo que el responsable de la producción o explotación de los
servicios. Pero, en cualquier caso, la definición de las formas de hacer se debe implicar
directamente a estos responsables, pues luego tendrán que aplicarlas a sus equipos.
Es complicado abordar la transformación interna contando únicamente con el per-
sonal de la empresa, pues con frecuencia se carece de los conocimientos, los perfiles
o la experiencia adecuados. Lo recomendable es contar con apoyo externo, en
forma de consultoría, para los tres aspectos: definición de procesos y procedimien-
tos, implantación de herramientas y formación y cambio cultural. Entre estos con-
sultores externos es conveniente asegurarse que siempre hay un perfil “evangeliza-
dor”, alguien que ayude a movilizar y motivar a los directores todavía reacios al
cambio, e insufle dinamismo y entusiasmo entre el personal.
Opción ideal: dependencia directa del Director de TI
Director de TI
Patrocinador SGSTI
CIO
Grupo implementación y
Planificación Dirección de Dirección de procesos TI
y control desarrollo producción
Opción frecuente: dependencia directa del Director de producción
Director de TI
CIO
Planificación Dirección de Dirección de

y control desarrollo producción
Patrocinador SGSTI
La propia dirección de producción es
consciente de la necesidad de mejora Grupo implementación y
e impulsa la implantación de procesos. procesos ISO/IEC 20000
Figura 4.15. Dos escenarios ejemplo de ubicación del grupo

de implementación del SGSTI
Dado que la transformación es un proceso continuo, este equipo creado ad-hoc para
el proyecto o los proyectos de implantación, suele constituirse en una estructura
estable en el tiempo. Este equipo muy centrado inicialmente en la implantación,
va evolucionado su actividad hacia la mejora continua de los servicios y de la activi-
dad de TI.
En las grandes organizaciones habría que tener en cuenta la necesidad de diversos tipos
de apoyo externo a lo largo del tiempo. A este respecto, en las más avanzadas, suelen
contratar una evaluación anual o bianual para identificar las fortalezas adquiridas y los
nuevos puntos de mejora. A veces, además de esta evaluación se suele realizar un
benchmarking comparativo con el mercado de los ratios más destacados de TI.
La aparición continua de normativa, que por una parte aporta ayuda a las empresas
pero que por otra acaba convirtiéndose en una nueva demanda del mercado, hace
que este equipo de implantación o de procesos de TI tenga garantizada una intensa
actividad para los próximos 10 años.
Las empresas deberán tener en cuenta, en sus estrategias y sus porfolios de proyec-
tos anuales, destinar una partida al proyecto de transformación continua de las for-
mas de hacer.
Monitorización, medición y revisión (Verificar)

Con el fin de determinar el grado de efectividad de la implementación del plan de
gestión del servicio se debe monitorizar, medir y revisar el grado de consecución
de los objetivos alcanzados. Tanto la parte 1 como la 2 de estas normas establecen
claramente los criterios a seguir:
UNE-ISO/IEC 20000-1
Objetivo: Monitorizar, medir y revisar que los objetivos y el plan de gestión del ser-
vicio se están cumpliendo.
El proveedor del servicio debe aplicar métodos adecuados para la monitorización y,
cuando sea necesario, la medición de los procesos de gestión del servicio. Estos
métodos deben demostrar la capacidad de los procesos para alcanzar los resulta-
dos planificados.
La dirección debe realizar revisiones a intervalos planificados para determinar si los
requisitos de gestión del servicio:
a) son conformes con el plan de gestión del servicio y los requisitos de esta
norma, y
b) se implementan y se mantienen de manera eficaz.
PDCA
Se debe planificar un programa de auditorías, teniendo en cuenta el estado y la

importancia de los procesos y las áreas que auditar, así como, los resultados de
las auditorías anteriores. Se deben definir en un procedimiento los criterios, el
alcance, la frecuencia y los métodos de la auditoría. La selección de los audito-
res y la realización de las auditorías deben garantizar la objetividad y la impar-
cialidad del proceso de auditoría. Los auditores no deben auditar su propio tra-
bajo.
El objetivo de las revisiones, evaluaciones y auditorías de la gestión del servicio se
debe registrar junto con las conclusiones de dichas auditorías, sus revisiones y las
acciones correctivas que se hayan identificado. Se debe comunicar a las partes
correspondientes la existencia de cualquier área significativa con alguna no confor-
midad u otra discrepancia.
UNE-ISO/IEC 20000-2
El proveedor del servicio debería plani- Los resultados del análisis deberían pro-
ficar e implementar la monitorización, porcionar una entrada a un plan para
la medición, el análisis y la revisión de la mejora del servicio.
los servicios, los procesos de gestión
Además de las actividades de gestión
del servicio y los sistemas asociados.
del servicio relativas a la medición y el
Entre los elementos que se deberían
análisis, es posible que la alta dirección
monitorizar, medir y revisar están los
necesite recurrir a auditorías internas y a
siguientes:
otros tipos de verificaciones. Al decidir
a) los logros respecto a los objetivos la frecuencia de dichas auditorías inter-
de servicio definidos; nas y verificaciones, se deberían tener
en cuenta, entre otros, factores como el
b) la satisfacción del cliente;
nivel de riesgo implicado en un pro-
c) la utilización de los recursos; ceso, su frecuencia de realización y su
historial de problemas pasados. Las
d) las tendencias;
auditorías internas y las verificaciones se
e) las no conformidades de mayor deberían planificar, registrar y llevarse a
consideración; cabo de una manera competente.
Mejora continua (Actuar)

Estas normas establecen claramente la necesidad de la realización de una mejora
continua, tanto en lo relativo a la mejora de los procesos implementados de gestión
del servicio, como en la mejora de los servicios prestados en sí mismos.
UNE-ISO/IEC 20000-1
Objetivo: Mejorar la eficacia y la eficiencia de la entrega y de la gestión del servicio.
Política:
Debe haber una política publicada sobre la mejora del servicio. Se debe corregir
cualquier no conformidad con la norma o con los planes de gestión del servicio.
Se deben definir claramente los roles y las responsabilidades para las actividades de
mejora del servicio.
Gestión de las mejoras del servicio:

Se deben evaluar, registrar, priorizar y autorizar todas las propuestas de mejora del
servicio. Se debe utilizar un plan para controlar la actividad.
El proveedor del servicio debe disponer de un proceso para identificar, medir y ges-
tionar las actividades de mejora e informar de dichas actividades de manera conti-
nua. Este proceso debe incluir:
a) las mejoras de un proceso aislado que el propietario del proceso pueda
implementar con los recursos de personal habituales, por ejemplo, la realiza-
ción de acciones correctivas y preventivas; y
b) las mejoras en toda la organización o en más de un proceso.
Actividades:
El proveedor del servicio debe realizar actividades para:
a) recopilar y analizar los datos para delimitar y medir la capacidad del provee-
dor del servicio para gestionar y proveer el servicio junto con los procesos de
gestión del mismo;
b) identificar, planificar e implementar mejoras;
c) consultar a todas las partes implicadas;
d) establecer objetivos de mejora en cuanto a la calidad, los costes y la utiliza-
ción de recursos;
e) tener en cuenta las aportaciones importantes, referentes a mejoras, que se
realicen desde todos los procesos de gestión del servicio;
f) medir, informar y comunicar las mejoras en el servicio;
g) revisar las políticas, los planes y los procedimientos de gestión del servicio,
siempre que sea necesario; y
h) asegurar que todas las acciones aprobadas se llevan a cabo y que se alcan-
zan los objetivos deseados.
PDCA
UNE-ISO/IEC 20000-2
Política: nado para cumplir con los requisitos de

la política desde su propia perspectiva y
Los proveedores del servicio deberían
desde la perspectiva del cliente.
reconocer que siempre existe la posibili-
dad de conseguir que la provisión del Antes de implementar un plan de
servicio sea más eficaz y más eficiente. mejora del servicio, se deberían regis-
Debería hacerse pública una política de trar los niveles de servicio y la calidad
la calidad y de mejora del servicio. del servicio como línea de referencia
Todas las personas implicadas en la sobre la que se puedan comparar las
gestión del servicio y la mejora del ser- mejoras reales. Para evaluar la eficacia
vicio deberían ser conscientes de la polí- del cambio se debería comparar la
tica de calidad del servicio y de cuál mejora real con la mejora prevista.
debería ser su contribución personal a la Nota 1: Los requisitos para la mejora del servicio
consecución de los objetivos estableci- pueden venir de todos los procesos.
dos en esta política.
En particular, todo el personal del pro- animar a su personal y a sus clientes a
veedor del servicio implicado en la ges- proponer alternativas para mejorar los
tión del servicio debería tener un cono-
servicios.
cimiento detallado de las repercusiones
de estos factores sobre los procesos de Nota 2: Esto se puede conseguir utilizando es-
gestión del servicio. quemas de sugerencias, círculos de cali-
dad, grupos de usuarios y reuniones de
Debería existir una coordinación eficaz coordinación.
entre la estructura de gestión propia del
proveedor del servicio, los clientes y los Los objetivos de la mejora del servicio
suministradores del proveedor del servi- deberían ser medibles, estar vinculados
cio a la hora de tratar cuestiones que con los objetivos de negocio y estar
afecten a la calidad del servicio y a los documentados en un plan.
requisitos del cliente. La mejora del servicio se debería gestio-
nar de una manera activa y se debería
Planificación de mejoras del servicio:
supervisar el progreso tomando como
Los proveedores del servicio deberían referencia los objetivos formalmente
adoptar un enfoque metódico y coordi- acordados.
En la mejora continua hay que distinguir dos tipos de mejoras: la mejora de los
procesos de gestión del servicio y la mejora propia de los servicios. Ambos tipos de
mejora redundarán en que la organización de TI funcione con más eficiencia, y en
que los servicios prestados sean de mayor calidad.
En el caso de la mejora de los procesos, las acciones de mejora de cada uno de ellos
las identifica y propone el propietario o el responsable del proceso. En relación a
las mejoras en cada uno de los servicios, las detecta, recopila de otras partes y pro-
pone cada uno de los gestores de nivel de servicio (véase el apartado 6.1). En ITIL,
para el conjunto de mejoras de uno o varios servicios agrupados en un plan se ha
acuñado el término de plan de mejora del servicio (SIP, Service Improvement Pro-
gram). Las acciones de mejora pueden abarcar todo tipo de actividad necesaria:
mejoras tecnológicas en los servicios, incorporación de herramientas, formación a
los involucrados, comunicación, mejora en la documentación, etc.
A la luz de lo establecido y recomendado por estas normas, parece razonable que
todas las acciones de mejora (de los procesos y de los servicios) se consoliden en una
planificación o un plan de mejora unificado, formado en base de los planes de
mejora de cada proceso y de cada servicio. De esta forma se tendrá una visión unifi-
cada de todas las acciones de mejora y las interrelaciones entre ellas. Este plan de
mejora unificado se puede ejecutar por fases y aplicando nuevamente el ciclo PDCA.
Las propuestas de mejora, que emanan de diversas fuentes (mejoras detectadas en
cada proceso, plan de mejora del servicio, iniciativas de calidad como Seis Sigma o
Lean, etc.), recopiladas por los gestores de los procesos, se agrupan para organizar-
las en un plan consolidado. Así, la mejora continua de la gestión del servicio se rea-
liza de una forma coordinada por un responsable único de esta actividad. En la
figura 4.16 se muestra la agrupación de las propuestas de mejora en un plan unifi-
cado común a toda la organización de TI.
Figura 4.16. La mejora de los procesos y de los servicios

se consolida en un plan unificado
PDCA
Resumen
La implementación de sistema de gestión del servicio de TI (SGSTI) está bien
especificada en las Normas ISO/IEC 20000 y debe seguir las 4 etapas del ciclo de
mejora continua de Deming (PDCA). En la figura 4.17 se muestra de nuevo la
aplicación de estas 4 etapas al SGSTI.
Plan Do Check Act

PLANIFICAR HACER VERIFICAR ACTUAR
Planificar Implementar Monitorizar, Mejora
la gestión la gestión medir y revisar continua
del servicio del servicio
Figura 4.17. Resumen de las 4 etapas del ciclo PDCA aplicadas

a la gestión del servicio
En la figura 4.18 se presenta un ejemplo de actividades y técnicas asociadas a cada una

de las etapas del PDCA. La etapa Plan lleva incluida el análisis de la situación actual.
Beneficios
La implantación de la gestión del servicio de TI siguiendo el ciclo PDCA y los
requisitos especificados y recomendados en las Normas ISO/IEC 20000, aportarán
entre otros, los beneficios siguientes:
• Permitirá que todas las actividades de transformación de la organización se
lleven a cabo de una forma controlada y organizada.
• Los objetivos se fijan en función de la situación de partida, obtenida
mediante una evaluación inicial.
• Los proyectos de implementación tienen unos objetivos fijados.
• Se monitorizan y miden los resultados de los proyectos.
• Se establece un plan de mejora continua.
• Se aprovecha la experiencia de otras organizaciones que iniciaron antes el
camino.
Técnicas asociadas al PDCA En la etapa Do se puede realizar:

• Ejecución de las acciones planificadas
en la fase de plan.
En la parte Plan se puede estructurar en:
• Ejecución de las mediciones oportunas
• Descripción del problema: para establecer una línea base.
– Diagramas de afinidad. • Ejercer un seguimiento de la ejecución
del plan.
• Recopilación de datos:
• Recopilación de la información
– Matrices. necesaria para la toma de decisiones
– Diagramas de control. entes de la fase check.
• Análisis de datos: En la etapa Check :
– Histogramas. • Ejercer un seguimiento de las acciones
implementadas.
• Formulación de las causas:
• Analizar los resultados.
– Diagramas de raspa.
• Evaluación de las mejoras.
– Diagramas de relaciones.
• Planificar la estandarización de las
– Diagramas de flujo.
mejoras si procede.
• Elaboración de hipótesis y • Tener en cuenta la posible resistencia
comprobación de hipótesis: de la organización al cambio.
– Histogramas. • Recopilar la información necesaria para
– Nubes de puntos. tomar la decisión de estandarizar o no.
• Identificar las causas raíz: En la etapa Act :

– Diagramas de raspa. • Supone establecer la nueva forma de
– Paretos. hacer las cosas que elimina las causas
de los problemas que se quería resolver.
• Propuesta de acciones: • Documentar la nueva manera de hacer
– Diagramas de árbol. las cosas.
• Evaluación y selección de acciones: • Informar a todas las partes implicadas
de los nuevos métodos de trabajo.
– Matrices.
• Proporcionar formación sobre la nueva
• Identificación de métricas: forma de hacer las cosas.
– Diagramas de tendencias. • Establecer los nuevos mecanismos de
– Histogramas. control para asegurar que la nueva
forma de hacer las cosas subsiste
• Planificación de las acciones: en la organización.
– Diagramas de flechas.
– Diagramas de Gantt.
Figura 4.18. Ejemplo de actividades y técnicas asociadas a cada etapa del PDCA
PDCA
• ¿Cómo se aplica el ciclo PDCA en su organización?
• ¿Cuál es la secuencia de implantación de los procesos que más se
adecua a su caso particular?
• En función de su experiencia, ¿qué otras recomendaciones de imple-
mentación añadiría a este capítulo?
1
5
Capítulo 5
Planificación e implementación
de nuevos servicios o de
servicios modificados


5. Planificación e implementación de nuevos servicios o de servicios modificados 151
Las organizaciones de TI, y las actividades que desarrollan, han sido tradicional-
mente vistas como un soporte interno al negocio, descuidando en general el uso de
criterios apropiados para medir su rentabilidad, eficacia y la calidad del servicio
ofrecido a toda la organización. Actualmente el entorno donde nos movemos, en el
que los horarios de disponibilidad de los servicios son cada vez más amplios, donde
las exigencias del cliente son cada vez más elevadas, y donde los cambios en el
negocio son cada vez más rápidos, es muy importante que los sistemas de informa-
ción estén adecuadamente organizados y alineados con la estrategia de la empresa.
La “planificación e implementación de nuevos servicios o de servicios modifica-
dos”, tiene la misión de garantizar que los servicios se puedan crear y entregar con
la funcionalidad, costes, calidad y plazos acordados con los clientes. Para ello hay
que gestionar el ciclo completo de la provisión y entrega de los servicios, realizando
una planificación unificada e integrada, asegurando que todas las partes implicadas
conocen y cumplen con el plan y los compromisos acordados.
En este capítulo se presenta una visión de este proceso, con un alcance más allá de
lo establecido en estas normas, definiendo el marco de un proceso nuevo que está
presente a lo largo de todo el ciclo de vida de la provisión de un servicio: desde la
elaboración de la propuesta de servicio, hasta la revisión después de su implanta-
ción, en el entorno de producción real. El proceso recorre y organiza con eficiencia
a toda la organización de TI, sirviendo como integración entre la estrategia del
negocio, el desarrollo de aplicaciones, el departamento de explotación o produc-
ción, y el área de planificación y control económico de TI.
Para las empresas que ya tengan implementada una metodología o un proceso de
gestión de los proyectos para el desarrollo de aplicaciones, este capítulo les apor-
tará nuevos puntos de mejora para incorporar y con ello enriquecer y complemen-
tar la metodología ya implementada, facilitando así la integración con los nuevos
procesos de gestión del servicio. Por tanto, este proceso utiliza las metodologías y
procesos existentes en la organización para cubrir parte de sus etapas. En este capí-
tulo no se aborda la descripción de la etapa de construcción (software y hardware)
del servicio, ni en las metodologías gestión de proyectos TI (PMBOK, PRINCE2,
etc.), aunque éstas serán necesarias para gestionar los proyectos de creación de los
servicios. También sería necesaria la utilización de otros estándares y mejores prác-
ticas relacionados con el desarrollo de software (SPICE o CMMI).
El lector comprenderá mejor los detalles de este proceso cuando haya profundizado
en el resto de procesos de gestión del servicio, pues utiliza gran parte de ellos. En
realidad, el capítulo se debería haber ubicado de los últimos del libro, pero se ha
decidido mantener la posición que tiene en las normas para conseguir una numera-
ción de capítulos similar.
Dada la extensión del título “proceso de planificación e implementación de nuevos

servicios o de servicios modificados”, en numerosas ocasiones a lo largo del capí-
tulo se hace referencia al mismo como “creación y evolución de los servicios”.
5.1. El proceso de planificación e implementación

de nuevos servicios o de servicios modificados
Figura 5.1. Esquema general del proceso de planificación e implementación

de nuevos servicios o de servicios modificados
Actualmente no basta con ser rápidos. Es necesario que el proceso de creación y

entrega de servicios TI se realice de forma eficiente y que el producto resultante
reúna los requisitos demandados por el cliente (véase la figura 5.1). Plazos, eficien-
cia y calidad son tres exigencias para el éxito empresarial.
Para conseguir el objetivo de gestionar y entregar tanto los nuevos servicios como
las modificaciones a los existentes con la calidad y costes adecuados, ISO/IEC
20000 esboza un proceso que se encarga de gestionar el ciclo completo de creación
de los servicios. Su ámbito de actuación abarca tanto los nuevos servicios como las
evoluciones de los que ya están en su fase de operación habitual.
En este capítulo se presenta el marco de un proceso completamente nuevo inspirado
a partir de los requisitos de ISO/IEC 20000. El proceso de creación de servicios, o
similar, no está contemplado explícitamente en ITIL. Aunque la v3 estructure sus
libros alrededor del ciclo de vida del servicio y proporcione gran cantidad de detalles
y buenas prácticas articuladas en diferentes procesos, no tiene un único proceso que
aglutine todas las actividades de las diferentes áreas de TI para una creación eficiente
de los mismos. La mayor semejanza a este proceso se encuentra en las metodologías

de desarrollo de software, que este proceso enriquecerá. Este nuevo proceso es impor-
tante para las organizaciones de TI, ya que incorpora las prácticas avanzadas de las
unidades que han tenido que responder de forma muy dinámica creando y evolucio-
nando servicios para poder atender al ritmo competitivo que les impone su negocio.
Los servicios no sólo se componen de código, además utilizan otros componentes
de infraestructura. También necesitan personal técnico que los administre y
soporte. Así, se debe analizar, desde el inicio del proyecto, la integración en la
arquitectura de TI, la disponibilidad, la capacidad, su continuidad, las necesidades
para su operación, etc. También, hay que formalizar con los clientes los acuerdos
de nivel de servicio a cumplir.
Este proceso tiene como punto de partida la estrategia de TI ya definida. A partir de
aquí, desde el momento en que se empieza a concebir la primera propuesta del servi-
cio, toma el control para no cederlo hasta el final, en la entrega a operación para su
explotación. Al superponer este proceso sobre el ciclo de vida del servicio planteado
en ITIL v3, se aprecia que recorrería las etapas de diseño y de transición (véase la figu-
ra 5.2). Pero las importantes disciplinas necesarias para la construcción o el desarrollo
de los servicios apenas se tratan: en el libro Diseño del Servicio se menciona la activi-
dad de “desarrollo de la solución de servicio”, mientras que en el libro de Transición del
Servicio se habla de la actividad de “construcción y prueba” del cambio y de la versión.
Alcance de la planificación e implementación de

nuevos servicios o de servicios modificados
en ISO/IEC 20000
Ciclo de vida del servicio en ITIL v3
ESTRATEGIA DISEÑO TRANSICIÓN
OPERACIÓN
MEJORA
CONSTRUCCIÓN
CONTINUA
(nótese que la construcción en ITIL v3 apenas se trata)
Figura 5.2. Alcance del proceso comparado con el ciclo de vida

del servicio de ITIL v3
El proceso de creación o evolución de servicios actúa como un proceso “director”,

que va encadenando y coordinando la participación de los otros procesos o funcio-
nes de TI. Comienza en el cliente para terminar con el servicio entregado y opera-
tivo. Para evitar duplicar funciones, utiliza los otros procesos de gestión del servicio,
como las relaciones con el negocio, la gestión de nivel de servicio, la generación de

informes del servicio, etc. Tal y como se aprecia en la figura 5.3.
Figura 5.3. El ciclo de creación de los servicios comienza en el cliente, termina

con los servicios operativos y utiliza el resto de procesos y actividades de TI
En el ámbito de TI, este proceso es el responsable de confeccionar una planifica-

ción integrada de todas las actividades necesarias para la creación de los servicios.
Garantiza que los nuevos servicios cumplirán con lo acordado con el cliente (pla-
zos, coste, funcionalidad y calidad) y que se construyen con las políticas y las nor-
mativas vigentes en la organización. Con la colaboración continua de todos los
procesos, funciones y departamentos involucrados, tratará de encontrar el equili-
brio correcto entre la demanda, la satisfacción del cliente y el coste de crearlos.
Gran parte de este proceso gestiona también las funciones habituales de la gestión de
proyectos de desarrollo de software en TI. Para cubrir estas funciones, posiblemente
ya se hayan implementado procesos y metodologías propios de la organización
o basados en estándares del mercado (SPICE, CMMI, PMBOK, PRINCE2, etc.).
En este escenario, el proceso de creación de servicios aporta una visión completa
de las actividades que se deben realizar para que el servicio que se va a construir
quede perfectamente operativo, incluyendo el diseño, la arquitectura, el desarrollo
de las aplicaciones, la creación de la plataforma tecnológica, los procedimientos de

operación, etc. Este proceso pone especial foco en la integración con los requisitos
ISO/IEC 20000. Se superpone sobre los procesos y metodologías de desarrollo
existentes para enriquecerlos e integrarlos con la gestión del servicio de TI. Por
tanto, no las debería reemplazar, sino enriquecer y coordinar para que los engrana-
jes de la creación de servicios funcionen sin fricciones en la organización. En la
figura 5.4 se muestra un ejemplo del alcance del proceso sobre las etapas típicas de
un proyecto de desarrollo de software.
Figura 5.4. El proceso de creación de servicios integra en su flujo a los procesos

de desarrollo de software y las metodologías de gestión de proyectos
Por tanto, este proceso es idóneo para la integración de las dos áreas de TI, tradi-
cionalmente separadas y mal engranadas: el desarrollo y la producción.
En la figura 5.5 se muestra un esquema global que integra el ciclo de vida ITIL v3,
con las etapas típicas de las metodologías de gestión de proyectos, los procesos de
desarrollo de software y la relación con el resto de los procesos de gestión del servi-
cio de TI contemplados en ISO/IEC 20000.
La creación y evolución de servicios orquesta una “cadena de fabricación” en TI,
que comienza con los requisitos del negocio y termina con los servicios operativos.
En un extremo de la cadena de fabricación está la necesidad del cliente de nuevas
funcionalidades de negocio y, en el otro extremo, se obtiene el servicio entregado y
operativo. El cliente, tras el tiempo acordado, espera recibir el servicio pactado que
cumpla con la funcionalidad, los costes y los acuerdos de servicio establecidos al
inicio del proceso. Justo entre estos dos extremos, es necesario desarrollar toda una
Figura 5.5. Ciclo tipo de creación de servicios en el marco de las actividades de TI
labor de fabricación que identifique todas las áreas y procesos de la organización

TI intervinientes y las coordine bajo un único plan de proyecto, hacia la consecu-
ción de las necesidades de los clientes, bajo criterios de calidad y eficiencia.
En la figura 5.6 se representa un símil de la “cadena de fabricación” que organiza
este proceso. En la parte superior, podemos ver los diferentes intervinientes que
participan en el proceso de creación y evolución de servicios, y cómo, a modo de
tolva, añaden su contribución a la creación de un nuevo servicio. Entre los intervi-
nientes se han incluido adicionalmente algunos procesos y funciones no contem-
plados en ISO/IEC 20000 (desarrollo de aplicaciones, construcción de la infraes-
tructura de TI y operación del servicio), que son fundamentales para poder realizar
una correcta planificación e implantación de los servicios. En la parte inferior se
representa este proceso que, a modo de cinta transportadora, va desplazando inexo-
rablemente al servicio a construir de una fase a otra en la línea de fabricación hasta
que, tras la entrega, se obtiene un servicio operativo y listo para ser utilizado por el
cliente.
Figura 5.6. El presente proceso orquesta la actividad de fabricación del servicio
Cada uno de los otros procesos que participan en la cadena tiene unos objetivos
específicos y su propio aporte a la construcción del servicio final. Aunque estos
procesos no se han tratado todavía en este libro, es conveniente tener una visión
general de su participación en este proceso. A continuación, se detallan los prin-
cipales:
Relaciones con el negocio. Su objetivo es establecer y mantener una buena rela-
ción entre el proveedor del servicio y el cliente, basándose en el entendimiento del
cliente y de los fundamentos de su negocio (véase el capítulo 7 para obtener más
detalles de este proceso).
El proceso de creación de servicios engrana con este proceso de relaciones para que
gestione todo el contacto necesario con las áreas de negocio. Su contribución se
centra en la toma de requisitos de las necesidades del cliente, la posterior negocia-
ción de la propuesta de servicio, la gestión del nuevo acuerdo de nivel de servicio y
el consenso con el cliente de la planificación para la creación del servicio realizada
por el proceso de creación. En su función “comercial”, durante el proceso de crea-
ción, se encarga de mantener informado al cliente y estar presente en las reuniones
de seguimiento, acompañando al jefe de proyecto. En la entrega, gestiona la parti-
cipación del cliente en las validaciones funcionales y en las reuniones para el cierre
del proyecto de creación.
Gestión de nivel de servicio. Su objetivo es definir, acordar, registrar y gestionar

los niveles de servicio que TI deberá cumplir y las relaciones con los clientes. Adi-
cionalmente mantiene el catálogo de servicios (véase el capítulo 6).
Su misión incluye la definición de los acuerdos de servicio de explotación (SLA,
Service Level Agreement) con todas las partes internas de TI implicadas. El cumpli-
miento del SLA lo asegura mediante una cadena de valor formalizada de otros
acuerdos internos de nivel operativo (OLA, Operacional Level Agreement), o con-
tratos de soporte (UC, Underpinning Contract) con los suministradores externos.
Elaboración de presupuestos y contabilidad de los servicios de TI. El objetivo

de este proceso es presupuestar y contabilizar los costes de la provisión del servicio.
En algunas organizaciones su actividad también incluye la facturación de los servi-
cios a los clientes.
Su contribución al presente proceso se centra en cómo se presupuestan los costes
de la creación del servicio con el suficiente detalle para que permita la toma de deci-
siones y el control económico efectivo. También realiza todo el seguimiento econó-
mico durante el proceso de creación del servicio.
Gestión de la capacidad. Su objetivo es asegurar que el proveedor del servicio TI

tiene, en todo momento, la capacidad suficiente para cubrir la demanda acordada,
actual y futura de las necesidades del negocio del cliente.
En esta cadena de fabricación participa en la etapa de diseño del servicio para deter-
minar los requisitos de capacidad, rendimiento y prestaciones de los nuevos servi-
cios o de sus evoluciones. Establece el plan necesario para darles cobertura contem-
plando los recursos, los plazos, los costes y los umbrales de gestión necesarios.
Gestión de la disponibilidad y continuidad. Su objetivo es asegurar que los

compromisos de continuidad y disponibilidad acordados con los clientes pueden
cumplirse bajo todas las circunstancias, ya sean por sucesos “domésticos” (como la
rotura de una unidad de almacenamiento), o por sucesos “extraordinarios” (como
una catástrofe natural, terremotos, incendios, etc.)
Su misión es la de identificar, para los nuevos servicios, los requisitos de disponibi-
lidad y de continuidad de los mismos sobre la base de los planes de negocio, los
SLA y las evaluaciones del riesgo. Los requisitos deben incluir los derechos de
acceso y los tiempos de respuesta, así como la disponibilidad extremo a extremo
de los componentes del sistema.
Gestión de la seguridad. Su objetivo es contemplar las necesidades seguridad de

la información de manera efectiva para todas las actividades del servicio.
Su responsabilidad es la identificación de los riesgos de seguridad del servicio en

base a la política de seguridad de la información de la compañía estableciendo las
medidas y controles necesarios para su eliminación o mitigación
Desarrollo de aplicaciones. Su objetivo es obtener, mediante construcción propia o

adecuación de una solución de mercado, la funcionalidad software adecuada que satis-
faga las necesidades demandadas por el cliente para cubrir sus funciones de negocio.
Su responsabilidad es la planificación, desarrollo y aseguramiento de la funcionali-
dad demandada de la forma más eficiente. Este área de TI es una de las más madu-
ras desde el punto de vista de normalización y utilización de metodologías
(PMBOK, PRINCE2, etc.), y buenas prácticas de mercado (SPICE, CMMI, etc.).
Gestión de la infraestructura TI. Su objetivo es implantar la infraestructura TI

necesaria y su gestión técnica, que alojará a los servicios en explotación.
En relación a este proceso, su contribución es la de proveer la infraestructura nece-
saria para alojar los nuevos servicios. Con mayor frecuencia es necesario realizar
proyectos complejos en los que intervienen diferentes tecnologías. Además este
área tiene un doble reto, ya que no sólo tiene que cumplir en sus compromisos de
cobertura a los requisitos de los nuevos servicios, sino que también debe controlar
y evitar el impacto negativo que estos proyectos podrían ocasionar en la prestación
habitual de los servicios existentes.
Gestión de suministradores. Su objetivo es garantizar la provisión sin interrupciones

de servicios de calidad cumpliendo con los contratos de soporte establecidos (UC).
En la construcción de servicios, realiza o revisa los contratos de soporte con los
suministradores para que los servicios estén acordes con los SLA que se están nego-
ciando con los clientes.
Gestión del cambio. Su objetivo es asegurar que todo cambio en TI se realiza

siguiendo las políticas de control y eficiencia definidas.
Su contribución se centra en controlar que el plan de proyecto de creación del
servicio esté claramente definido y documentado, de forma que pueda ser valorado,
aprobado, implementado y revisado de una manera controlada.
Gestión de la entrega. Su objetivo es gestionar la implantación, distribución y el

seguimiento de uno o más cambios a realizar en el entorno de producción real.
Para este proceso, realiza la implantación y despliegue del servicio nuevo o modifi-
cado en el entono de producción de la forma más fiable y eficiente posible. Mini-
miza el impacto negativo que pudiera tener en el servicio operativo habitual.
Operación y soporte del servicio. Se encarga de todas las actividades necesarias

para que un servicio esté operativo y disponible a los usuarios. La operación es una
de las grandes olvidadas en el proceso de creación de servicios, pero si no se dis-
pone de una operación diaria acorde a las necesidades del cliente, este nuevo servi-
cio, aunque se haya construido por TI en plazo y forma, para el cliente es como si
no existiera.
Su contribución es la de establecer los requisitos que permitan que el servicio se
pueda explotar adecuadamente. Además, realiza la definición y preparación del
soporte, de la planificación y de la operación diaria de los servicios, garantizando el
cumplimiento de los requisitos de ejecución establecidos en los SLA.
Hasta este punto se han podido observar los objetivos y ámbito de actuación de
este proceso de creación y modificación de servicios de TI. La figura 5.7 propor-
ciona un resumen de este proceso: una definición, el objetivo formalizado en las
Normas ISO/IEC 20000 y las principales aportaciones del proceso.
Planificación e implementación Qué aporta:

de nuevos servicios o de • Implementa un ciclo completo de
servicios modificados creación y entrega de servicios,
desde las necesidades y acuerdos
con el cliente hasta su entrega y
puesta en funcionamiento operativo.
Definición: • Los servicios se crean de una forma
eficiente.
Proceso que se responsabiliza de la
fabricación de servicios utilizando • Los servicios se crean en los
plazos acordados, velando por las
el resto de procesos y funciones
necesidades del negocio en el
de la organización TI.
time-to-market.
• Los servicios TI se diseñan para
Objetivo: satisfacer las necesidades reales
del cliente y cumpliendo con la
Asegurar que, tanto los servicios arquitectura y políticas de
nuevos, como las modificaciones la organización.
a los existentes, se pueden gestionar • Los servicios se crean con la
y entregar con los costes y la participación de todas las áreas
calidad acordados. de la organización de TI: gobierno,
arquitectura, desarrollo y explotación.
• La organización TI y sus clientes
tienen unas expectativas claras
y formalizadas del servicio
solicitado a TI.
Figura 5.7. Introducción general al proceso

Los principales factores clave en torno a los que se articula este proceso se resumen en:
• Cumplimiento de los plazos, atendiendo a la agilidad y tiempo de respuesta
de la organización de TI ante necesidades del negocio.
• Cumplimiento de la funcionalidad demandada.
• Gestión eficiente de los costes.
• Cumplimiento de las políticas establecidas en TI, tanto para la construcción
del servicio y de sus componentes, como para la articulación de su puesta en
producción.
• Velar por la calidad necesaria demandada por el negocio.
• Integración de las soluciones en las arquitecturas TI existentes, tanto de:
datos, de aplicaciones, de componentes, tecnológica de hardware-software, de
seguridad, etc.
En la figura 5.8 se resumen estos factores clave que estructuran y rigen la actividad
de este proceso en las relaciones intensas y constantes con los intervinientes en la
creación o evolución de un servicio TI.
Figura 5.8. Los factores clave del proceso

El conocimiento y correcto manejo de estos factores permitirá a este proceso ges-

tionar adecuadamente la creación de nuevos servicios, o las modificaciones a los
existentes, con los costes y calidad acordados con el cliente. Además, el gestor de
este proceso debe conseguir estos objetivos dentro de un marco estratégico, téc-
nico y humano del proveedor de servicios TI.
El proceso de planificación e implantación de nuevos servicios o de servicios modi-
ficados utiliza las funciones del proceso de relaciones con el negocio, que gestiona
las necesidades del cliente, y articula al resto de la organización de TI, con el obje-
tivo de asegurar que, tanto los servicios nuevos, como las modificaciones a los exis-
tentes, se puedan gestionar y entregar con los costes, plazos y la calidad acordados.
En la figura 5.9 se puede muestran los componentes más destacados que utiliza
este proceso para realizar su actividad. Se estructuran en dos ciclos, uno centrado
en acordar con el cliente y diseñar los servicios, y el otro, en construirlos y entre-
garlos.
COMPONENTES DEL PROCESO
DISEÑO CONSTRUCCIÓN TRANSICIÓN
Cliente
Servicio
Requisitos
del servicio Planificación Informe
del proyecto de pruebas
Políticas, procesos desarrollo de software,
metodología gestión de proyectos
Especificaciones
técnicas
y arquitecturas
de servicio
OLA y UC
Acuerdos internos con áreas,
procesos, funciones
Propuesta
y suminstradores
de servicio
Lista de
cambios
Solicitud
RFC planificados
SLA de cambio
(FSC)
Figura 5.9. Componentes principales de las etapas de diseño y transición del proceso
A continuación, se describen los componentes relacionados con este proceso:

Cliente. Es el representante de una organización que está autorizado a cerrar acuer-
dos en nombre del negocio sobre la adquisición de servicios TI. Es decir, el cliente
es la persona física o representante de una entidad jurídica que paga por los servi-
cios TI. Por esta razón, los clientes representan a las áreas de negocio de la empresa
y, por tanto, no coinciden con los usuarios finales, ya que estos últimos son aque-
llos que utilizan los servicios TI.
Servicio TI. Se puede definir como un conjunto de funciones relacionadas, pro-

porcionadas por sistemas de TI que dan soporte a una o más áreas de negocio
(departamentos, agencias, etc.). Un servicio puede estar compuesto de diversas
piezas de software, de hardware y de elementos de comunicación, pero el cliente y el
usuario final que lo utiliza, lo perciben como una funcionalidad “autocontenida y
coherente”.
Cultura de servicio. Implica que la satisfacción del cliente es la prioridad principal

para todos los miembros de la organización TI que ofrece servicios. Se controla que
las actividades llevadas a cabo en la provisión de los servicios contribuyen a los
objetivos de negocio.
Gestión de la demanda. Es la actividad realizada por las relaciones con el negocio

para manejar la demanda de nuevos servicios, o de la evolución de los existentes,
de las áreas clientes de TI. La gestión de la demanda trata de acoplar la demanda
del día a día, con las previsiones (anuales) reflejadas en los presupuestos y desarro-
lladas en el porfolio de servicios.
Requisitos de nivel de servicio (SLR, Service Level Requirements). Es un docu-

mento que describe de forma detallada las necesidades del cliente. La descripción
se realiza en el lenguaje del cliente para facilitar su entendimiento y validación. Este
documento contiene la información de la funcionalidad a proveer por el servicio.
Se debe formalizar con el cliente, pues, sobre esta base, se desencadena todo el pro-
ceso de creación.
Análisis de viabilidad o caso de negocio. Estudio de los beneficios obtenidos del

proyecto frente a los costes, para asesorar a la dirección y a la gestión del cambio
sobre la idoneidad o no de abordar el proyecto. Normalmente sólo se realiza para
grandes proyectos. Suele incluir el cálculo del coste total de propiedad del nuevo
servicio (TCO, Total Cost of Ownership) y el cálculo de retorno de la inversión
(ROI, Return Of Investment).
Especificaciones técnicas del servicio. Documento que describe la relación entre la

funcionalidad requerida por el cliente y la tecnología empleada para implementarla.
Este documento describe los requerimientos técnicos que son necesarios para la
provisión y entrega del servicio.
Acuerdo de nivel de servicio (SLA, Service Level Agreement). Documento que

recoge los compromisos acordados entre el cliente y el proveedor de servicios de
TI para la provisión del servicio requerido. En este documento se detallan por
escrito los objetivos de los servicios y las responsabilidades de ambas partes. El SLA
se describe en el apartado 6.1 de este libro.
Acuerdo de nivel operativo (OLA, Operational Level Agreement). Documento

que formaliza los compromisos entre departamentos internos de la organización
de TI relativos a su contribución en la provisión, la entrega y la prestación de un
servicio.
Este acuerdo interno establece responsabilidades, actividades, recursos, esfuerzo,
plazos y costes del mismo. También contempla los compromisos internos para la
prestación y operación habitual del servicio. El OLA se describe en el apartado 6.1
de este libro.
Contrato de soporte (UC, Underpinning Contract). Documento contractual

entre la organización de TI y un suministrador de servicios externo. Este contrato
define los objetivos, alcance y características del servicio a prestar, así como los pla-
zos y costes asociados.
Al igual que el acuerdo de nivel operativo, el contrato de soporte interviene en la
confección del SLA y del plan de proyecto para la creación del servicio. El UC se
describe en el apartado 6.1 de este libro.
Propuesta de servicio. La propuesta de servicio cubre la información necesaria

para establecer el acuerdo con el cliente (funcionalidad, plazos, costes y calidad)
relativo a la creación y entrega del servicio.
También se contempla, aunque no se muestra al cliente, la parte interna necesaria
de TI. Se detalla las unidades que van a intervenir en la creación del servicio, los
plazos de elaboración y entrega de sus actividades. Establece los mecanismos de
gestión y seguimiento necesarios para analizar la evolución de los trabajos compro-
metidos con el cliente.
Planificación del proyecto. Planificación detallada de todo el proceso de cons-

trucción y transición del servicio. Integra los compromisos de todas las áreas,
internas (OLA) y externas (UC) intervinientes, sobre la aportación que cada uno
va a realizar a la provisión e implantación del servicio. Esta planificación del pro-
yecto esta sujeta al control del cambio.
Solicitud de cambio (RFC, Request For Change). Formulario utilizado para pro-
poner un cambio en cualquier componente de la infraestructura de TI o en cual-
quier aspecto de un servicio de TI. En este caso contempla la creación de un servi-
cio o la modificación de uno existente.
En la RFC se reflejan la naturaleza, los detalles, la justificación y la autorización del
cambio propuesto. La RFC va actualizándose a lo largo de la vida de la creación
del servicio. La RFC se describe en el apartado 9.2 de este libro.
Lista de cambios planificados (FSC, Forward Schedule of Change). Es una pro-

gramación unificada de todos los cambios en curso que recoge los detalles de los
cambios cuya implantación haya sido aprobada, así como las fechas propuestas para
las aprobaciones intermedias que permitan la implantación segura de los servicios.
En ITIL v2 se denomina FSC, mientras que en la v3 se ha cambiado el término por
“lista de cambios” o change schedule. La lista de cambios planificados se describe en
el apartado 9.2 de este libro.
Entradas, actividades y salidas del proceso

Cuando sobre el modelo de procesos ITIL se intenta representar el flujo que debe-
ría seguir la creación de un nuevo servicio, se obtiene una auténtica maraña de
líneas de flujo que entran y salen prácticamente de todos los procesos. Esto
se debe a que la creación de servicios es un flujo que se superpone a todos los
otros procesos.
Este proceso actúa como el “director de la orquesta de TI”, que hace que toda la
organización trabaje sincronizada en la creación y evolución de servicios. Se alinea
con las necesidades demandadas por cliente, velando por los elementos críticos de
su demanda: plazo, funcionalidad, costes y calidad. Para realizar esta labor, las rela-
ciones con los otros procesos y los diferentes departamentos de TI son intensas y
constantes.
En la figura 5.10 se muestra un esquema con las principales entradas, actividades
y salidas de este proceso.
Las entradas que desencadenan el inicio del proceso de creación de servicios son la
solicitud del cliente (en una reunión o mediante una petición expresa), la puesta en
Entradas Actividades Salidas
Desencadenantes 3 Gestión de la demanda. Salidas principales:

del proceso: Necesidades. Ü Servicio operativo.
Ü Solicitud del cliente. 3 Requisitos del servicio (SLR).
Ü Documentación del
Ü Porfolio de proyectos. 3 Análisis de viabilidad servicio: de usuario,
(TCO y ROI). técnica y para el SD.
Ü Mandato de la dirección
3 Especificaciones técnicas del
de TI. Ü Servicio cargado
servicio.
en herramientas de
Entradas de soporte: 3 Propuesta del servicio y
autorresolución.
del SLA.
Ü Catálogo de servicios. Ü Contrataciones
3 Plan de proyecto para la
Ü Políticas. creación del servicio. necesarias.
Ü Metodologías proyectos. 3 Revisión y formalización Salidas secundarias:
Ü Arquitecturas TI. de acuerdos internos y
Ü SLA cerrado.
contratos (OLA y UC).
Ü SLA existentes.
3 Solicitud de cambio (RFC) y Ü OLA y UC actualizados.
Ü OLA y UC existentes. aprobación de la creación Ü Catálogo de servicios
Ü CMDB. del servicio. actualizado.
3 Seguimiento del proceso de Ü FSC actualizado.
construcción.
Ü DSL actualizada.
3 Integración y pruebas del
servicio construido. Ü CMDB actualizada.
3 Aprobación de la implantación. Ü Informes de errores en
3 Implantación y despliegue. las pruebas a desarrollo.
3 Revisión posimplantación. Ü Propuesta de actividades

para la mejora del
3 Comunicación de resultados y
cierre. servicio.
3 Supervisión funcionamiento del

proceso.
3 Informes, análisis y acciones de
gestión del cambio.
Mejora del proceso.
Fuente: e.p. y Telefónica.
Figura 5.10. Entradas, actividades y salidas del proceso
marcha de un proyecto definido en el porfolio o cartera de proyectos de TI, o bien

por actuación expresa de la dirección de TI.
Hay otras entradas que se utilizan en el proceso de apoyo a la realización de una
actividad. Las principales entradas de soporte son: el catálogo de servicios, para
determinar si la necesidad del cliente está cubierta por el catálogo; las políticas,
metodologías de gestión de proyectos y las arquitecturas TI con el fin de que la cre-
ación del nuevo servicio sea acorde con todo lo dictado en la organización; los
SLA, OLA y UC existentes; y la CMDB para proveer todo tipo de información
sobre TI y sus elementos de configuración.
Las actividades principales que realiza este proceso son:
• Gestión de la demanda, realizada por relaciones con el negocio (cliente) para
profundizar en sus necesidades, determinación de si éstas están en el catálogo
de servicios, y su encaje en las previsiones presupuestarias y en el porfolio de
servicios.
• Establecimiento de los requisitos del servicio por parte del cliente (SLR).
• Realización, si procede, del análisis de viabilidad (TCO y ROI).
• Elaboración de las especificaciones técnicas del servicio, que incluye su arqui-
tectura y el diseño funcional y técnico.
• Elaboración de la propuesta del servicio y del SLA.
• Realización del plan de proyecto para la creación del servicio.
• Revisión y formalización de acuerdos internos y contratos (OLA y UC).
• Confección de la solicitud de cambio (RFC) y aprobación de la creación del
servicio. Dar la orden del inicio de la construcción del servicio.
• Seguimiento del proceso de construcción.
• Realización de la integración y pruebas del servicio construido, en el entorno
de pruebas-integración.
• Aprobación de la implantación del servicio por gestión del cambio.
• Realización de la implantación y despliegue del servicio.
• Revisión post-implantación.
• Comunicación de los resultados a todas las partes interesadas.
• Cierre de la implantación y de la solicitud de servicio.
Las salidas principales del proceso son: el servicio operativo y listo para que pro-
vea las funcionalidades al negocio especificadas; todo tipo de documentación aso-
ciada necesaria (de usuario, para las áreas técnicas, de soporte para la atención de
incidentes y peticiones del usuario, etc.); el servicio cargado en las herramientas
de autorresolución al usuario; y las contrataciones necesarias realizadas (para la
construcción, para el soporte técnico de los fabricantes, para el mantenimiento de

licencias).
Las salidas secundarias del proceso son: el SLA de explotación del servicio, los
OLA y UC revisados, el catálogo de servicios actualizado con el nuevo servicio o
nuevas funcionalidades, la lista de cambios planificados actualizada (FSC), la
biblioteca de software definitivo (DSL) y la base de datos de gestión de la configu-
ración (CMDB) actualizadas con el nuevo servicio, los informes en los errores en
las pruebas y la propuesta de actividades para la mejora del servicio y del proceso
que se incorporará en el plan de mejora general.
En la figura 5.11 se muestra una secuencia de actividades del proceso, con foco en
la relación con otros procesos de gestión del servicio de TI. Estas actividades se
deberían integrar también en la metodología de desarrollo de proyectos de la orga-
nización de TI.
Planificación e implementación de servicios nuevos o de servicios modificados
Relaciones Actividades específicas Gestión Gestión de

con el negocio del proceso del cambio la entrega
Gestión demanda.
Necesidades frente a
catálogo de servicios Análisis de viabilidad
Requisitos de servicio Especificaciones técnicas • Aprobación preliminar
del cliente (SLR) del servicio (SS)
Negociación propuesta Propuesta del servicio y SLA
servicio y SLA
Acuerdo con el cliente Plan de proyecto del servicio
Revisión y formalización de • Aprobación del RFC de
acuerdos y contratos (OLA, UC) creación/evolución
del servicio
Confección solicitud • Aprobación planificación
de cambio (RFC) • Inclusión en FSC
Orden de construcción • Gestión del cambio
Construcción del servicio. Pruebas del servicio (por otros procesos y departamentos TI)
Aprobación implantación Integración y pruebas

por cambios
Implantación y despliegue
Comprobación
posimplantación Revisión posimplantación
Comunicación
entrega del servicio. Comunicación
CIERRE SOLICITUD resultados implantación. SERVICIO OPERATIVO
SERVICIO CIERRE IMPLANTACIÓN
Figura 5.11. Secuencia de actividades principales del proceso con foco

en la integración con otros procesos de gestión del servicio
A continuación, se detallan las principales actividades para el ciclo de creación de

servicios.
El proceso se inicia con las “relaciones con el negocio”

La gestión de la relación con el negocio se encarga de todo lo relativo a la relación
entre el proveedor de servicio TI y el cliente. Se podría decir que lleva las relaciones
“comerciales” de TI para la “fábrica”.
En ITIL v3, en el ámbito de la estrategia del servicio, se establece una completa
serie de actividades en torno a los procesos de la gestión de la estrategia, la gestión
financiera, la gestión de la demanda y la gestión del porfolio de servicios (no
cubiertos por ISO/IEC 20000). El proceso de creación de servicios se desencadena
por una solicitud del cliente, por la ejecución del porfolio de servicios o por man-
dato de la dirección de TI, pero siempre dentro del contexto definido en la estrate-
gia y manteniendo la implicación directa del cliente.
El ciclo de la creación debe comenzar con el proceso de gestión de las relaciones
con el negocio, que se encarga de diálogo con el cliente. Para intentar dar cober-
tura a sus necesidades utilizará la oferta estándar de servicios de TI, basándose en el
catálogo de servicios existente. Si la necesidad del cliente se satisface con un servi-
cio del catálogo, se ejecuta una solicitud de servicio, que se proveerá por el medio
de provisión predefinido. Si no se pueden resolver con un servicio preexistente, se
desencadenaría la creación de uno nuevo o a la evolución de uno existente, dando
paso al resto del proceso.
En todo caso se debe encajar la necesidad del cliente con las previsiones presupues-
tarias y con las previsiones de proyectos o servicios a realizar, definidas normal-
mente el porfolio o cartera de proyectos o servicios.
Requisitos de servicio del cliente (SLR, Service Level

Requirements)
Este gestor de relaciones con el negocio debe escuchar al cliente, analizar sus
necesidades y formalizarlas en un documento de requisitos de servicio del cliente
(SLR) y si estas no se ajustan a la oferta estándar de servicios, se analizaría la
posibilidad de poder proveerlas (para un mayor detalle véase el apartado 7.2).
En esta actividad es necesario aplicar las disciplinas de formalización de los requi-
sitos de los clientes (para lo que se recomienda seguir lo especificado en CMMI
al respecto).
Análisis de viabilidad (TCO y ROI) o caso de negocio

Con frecuencia, en las organizaciones TI se toman decisiones de inversión impor-
tantes sin un análisis adecuado de las mismas. Aunque por otra parte, hay que evi-
tar “la parálisis de la organización por el análisis”.
En el caso de los proyectos o servicios que requieran altas inversiones, es conve-
niente realizar un estudio de los costes totales del nuevo servicio, en todo su ciclo de
vida, para contrastarlo con los beneficios que se aportará al negocio. En el análisis
se suele calcular el coste total de propiedad del nuevo servicio (TCO) y el cálculo del
período de tiempo necesario para el retorno de la inversión (ROI).
Con estos datos, se toma la decisión de abordar o no el proyecto, o reorientarlo
hacia otro tipo de solución más adecuada. Esta decisión se recomienda que la tome
el comité de cambios, o si no, la propia dirección de TI.
Especificaciones técnicas del servicio

En el caso que sea necesario construir un nuevo servicio o evolucionar uno exis-
tente este proceso toma el control e inicia su primera actividad propiamente dicha:
convertir los requisitos del cliente en especificaciones técnicas internas. Su objetivo
es detallar las especificaciones técnicas del servicio partiendo del documento de
requisitos del cliente (SLR).
Con la colaboración y trabajo conjunto de gestión de nivel de servicio y el resto de
procesos y funciones implicadas, se elabora un documento que describe la relación
entre la funcionalidad requerida por el cliente y la tecnología empleada para
implantarla. Este documento describe los requisitos técnicos que son necesarios
para la provisión y entrega del servicio, contemplando la siguiente información:
• Descripción técnica detallada e inequívoca de los servicios demandados por
el cliente y sus componentes TI.
• Especificación del modo en el que el servicio va a ser aprovisionado e implan-
tado por TI (utilización de arquitecturas ya definidas, plataformas de pro-
ducción existentes, etc.).
• Especificación de los requisitos de control de calidad necesarios.
Estas especificaciones describen con detalle lo que el cliente desea y cual es el impacto
que tiene en la organización TI, su provisión, implantación y operación. Este docu-
mento de uso interno no necesita ser firmado por el cliente, pero si está sujeto al con-
trol documental establecido por el sistema de gestión del servicio de TI (SGSTI).
El contenido recomendado del documento de especificaciones técnicas del servicio

debería contener, como mínimo, los conceptos indicados en la figura 5.12.
Especificaciones técnicas del servicio
1. Introducción
• Objetivo y alcance.
• Nombre del cliente/SLR de referencia.
2. Descripción del servicio
• Nombre del servicio, objetivos y alcance.
• Requerimientos de alto nivel:
– Funcionalidad.
– Horario de servicio y soporte.
– Disponibilidad, fiabilidad y continuidad.
– Rendimiento y volúmenes.
– Interfaces, etc.
3. Estructura y propuesta de nivel de servicio
4. Planificación
• Fecha requerida de disponibilidad del servicio.
• Duración del servicio.
5. Relaciones con otros elementos de configuración
• Servicios, componentes hardware y software.
6. Unidades involucradas la creación del servicio
• Nombre del departamento, responsable, datos
de contacto y requerimientos técnicos, humanos
y económicos asociados.
7. Servicios impactados
• Nombre del servicio y descripción del impacto.
Figura 5.12. Contenido del documento de especificaciones técnicas del servicio
Propuesta de servicio y acuerdo de nivel de servicio

(SLA, Service Level Agreement)
Una vez realizadas las especificaciones de servicio, que describen la solución técnica a
los requisitos del cliente y que proporciona las definiciones técnicas necesarias para
proveer e implantar el servicio, se está en disposición de confeccionar la propuesta de
servicio y, realizado por el proceso de gestión de nivel de servicio, el acuerdo de nivel
de servicio (SLA) preliminar. Esta propuesta se presentará al cliente como respuesta a

su demanda para su revisión negociación y acuerdo. Al respecto, ISO/IEC 20000-1
establece:
UNE-ISO/IEC 20000-1
En las propuestas de nuevos servicios o modificaciones en los existentes, se deben

considerar los costes y el impacto a nivel organizativo, técnico y comercial que
pudiera derivar de su entrega y gestión.
En esta etapa TI formaliza dos tipos de acuerdo con el cliente:

• La propuesta de servicio, que es el acuerdo de creación del servicio (aplica-
ción, infraestructura, etc.), a veces conocido como “SLA de desarrollo” o
“SLA de construcción”.
• El SLA del servicio, centrado exclusivamente en las condiciones de presta-
ción operativa del servicio que recibirá el cliente, en ocasiones denominado
sólo como “SLA” o como “SLA de explotación” (véase el apartado 6.1).
La propuesta de servicio cubre el acuerdo con el cliente (en funcionalidad, plazos,

costes y calidad), para la creación y entrega de los servicios. La responsabilidad de
su confección directa es del proceso de planificación e implementación de servicios
nuevos o modificados (es el primer documento que genera de forma específica este
proceso, pues los otros son generados por los procesos o áreas que coordina).
En la propuesta de servicio también se contempla, aunque no se muestre al cliente,
la parte interna de TI asociada. Se detallan: quién interviene en su realización, los
plazos de elaboración y entrega de las actividades, y los mecanismos de gestión y
seguimiento necesarios para analizar la evolución de los trabajos comprometidos
con el cliente. Para poder realizar esta última parte es necesario acordar y formali-
zar, con todos los intervinientes de TI, su participación, sus necesidades en cuanto
a los plazos, los recursos y los costes.
También se debe contemplar en la propuesta los indicadores y métricas de gestión,
así como los mecanismos necesarios para la revisión del servicio y para el control,
el seguimiento y la evaluación interna del cumplimiento de los niveles de servicio
acordados. En este punto, es importante resaltar que antes de proponer estos meca-
nismos es necesario verificar previamente, con las áreas y procesos involucrados,
que la organización TI cuenta con los medios de monitorización necesarios para
obtener las métricas acordadas ya que, a menudo, se olvida este aspecto y luego no
es posible conocer si se están cumpliendo los SLA firmados. En la figura 5.13 se
muestra el contenido habitual de una propuesta de servicio.
Propuesta de servicio para negociar

con el cliente
1. Objetivos y alcance.
2. Descripción del servicio:
• Funcionalidad.
• Seguridad y continuidad.
3. Estimación de recursos necesarios del cliente.
4. Estimación de plazos de creación y entrega.
5. Estimación de costes asociados.
6. Impacto y modificaciones a contratos y acuerdos
existentes.
7. Propuesta SLA:
• Compromisos de prestación regular del servicio en
términos medibles.
• Indicadores y métricas de gestión del
cumplimiento.
• Mecanismos de control y seguimiento de la
evolución de los niveles de servicio acordados.
8. Criterios de aceptación del servicio.
9. Participantes y sus responsabilidades en las
actividades de creación, implantación, operación
y evolución de los nuevos servicios. Contemplar
las actividades a llevar a cabo por los clientes y
el proveedor de servicio TI.
Figura 5.13. Propuesta servicio a negociar con el cliente
El SLA del servicio describe las condiciones de la prestación regular del mismo
durante el tiempo que dure el acuerdo. Contiene los compromisos de TI y del cliente
para prestación del servicio y será la referencia que se utilizará por las dos partes para
medir la prestación del servicio. En el ámbito de este proceso se formaliza el SLA,
pero su realización corresponde al proceso de gestión de nivel de servicio (SLM),
trabajando para este proceso. Este punto se trata detalladamente en el apartado 6.1.
La propuesta de servicio describe en términos de negocio “qué” se entregará al
cliente y “cuándo”; y el SLA contiene los compromisos de ambas partes para la
prestación habitual del servicio. Estos documentos constituyen el medio por el que
las dos partes, cliente y proveedor de servicios TI, pueden medir los compromisos
tanto del cumplimiento de la creación del servicio como los de su prestación regu-
lar durante su vida útil.
Negociación de la propuesta de servicio, de la

planificación y del SLA
La propuesta de servicio, que incluye una planificación preliminar del proyecto de
construcción, y el SLA de explotación, se revisan y negocian con el cliente para
ajustar los objetivos, calidades, plazos y costes, entre lo demandado por el cliente y
lo que la organización de TI razonablemente puede aportar. Una vez llegado a un
acuerdo, se firman estos dos documentos por ambas partes. Esta actividad la rea-
liza el proceso de relaciones con el negocio bajo el paraguas de este proceso.
Destacar la recomendación realizada en ITIL v3 en el libro Transición del Servicio
relativa a que el SLA (de explotación) se cierre definitivamente después de una fase
piloto o al principio de la vida del servicio (early life support) antes de que la transi-
ción se haya terminado.
Plan de proyecto para la creación del servicio

Una vez formalizada la propuesta de servicio, se realiza el plan de proyecto, desde
la perspectiva pura de TI, para la creación del servicio. En esta actividad se realiza
el análisis detallado de las tareas a realizar por cada uno de los intervinientes, con-
feccionando una planificación detallada de creación del servicio.
UNE-ISO/IEC 20000-1
La planificación e implementación deben incluir los fondos y recursos adecuados

para llevar a cabo los cambios necesarios para la provisión y la gestión del servicio.
Los planes deben incluir:
a) los roles y responsabilidades para implementar, operar y mantener los nuevos
servicios o modificaciones en los existentes, incluyendo las actividades a llevar
a cabo por clientes y suministradores;
b) los cambios en el marco de trabajo existente de gestión del servicio y en los
propios servicios;
c) la comunicación a las partes afectadas;
d) los nuevos contratos y acuerdos, o modificaciones a los contratos y acuerdos
existentes, para estar alineados con las necesidades del negocio;
e) los requisitos de mano de obra y contratación;

f) los requisitos de perfiles y formación, por ejemplo usuarios, soporte técnico;
g) los procesos, medidas, métodos y herramientas que han de usarse con rela-
ción a los nuevos servicios o modificaciones en los existentes, por ejemplo ges-
tión de la capacidad, gestión financiera;
h) los presupuestos y plazos de tiempo;
i) los criterios de aceptación del servicio; y
j) los resultados esperados al operar con el nuevo servicio, expresados en términos
medibles.
La planificación se debe confeccionar en términos de objetivos, alcance, funcionali-

dad, estimación de plazos para que esté disponible, esfuerzo y costes asociados.
Este documento integra toda la información necesaria para los proveedores inter-
nos y externos sobre la aportación que cada uno debe realizar a la provisión e
implantación del servicio. También define los parámetros necesarios para los proce-
sos de gestión de servicio, la administración y la operación.
Para realizar la planificación del proyecto y la gestión de todas sus etapas se utilizan
metodologías como PMBOK o PRINCE2.
Durante la elaboración del plan de proyecto es necesario revisar y formalizar los
acuerdos internos y los externos a la organización de TI, que involucran a todas las
áreas y departamentos del proveedor de servicios.
Se puede definir el plan de proyecto de servicio como el documento donde el pro-
veedor de TI especifica el proceso de fabricación con el que se elaborará y entre-
gará un servicio. Es decir, describe el plan de trabajo que se habrá de realizar por
cada área y proceso TI para la construcción, pruebas, despliegue y puesta en mar-
cha del servicio. Este documento establece, por tanto, las fases, actividades, hitos,
planificación, responsabilidades, plazos de disponibilidad, costes e indicadores aso-
ciados al servicio, los cambios en la Infraestructura TI necesarios, así como las
características de los acuerdos que habrá que establecer, tanto en el ámbito interno
de la Organización TI como de los suministradores externos.
Este plan de proyecto, al igual que el resto de documentos, estará sometido al con-
trol de la gestión documental del sistema de gestión de servicios de TI (SGSTI).
El contenido base de este documento se presenta en la figura 5.14.
La participación de cada área o suministrador de TI en el plan de proyecto se debe-
ría formalizar mediante “acuerdos de nivel operativo” (OLA, Operational Level
Agreement) cuando se trata de áreas internas a la organización de TI y para el caso
Plan de proyecto de creación del servicio
1. Introducción:
• Clientes, SLR y SLA de referencia.
• Fecha de inicio servicio.
2. Procesos y departamentos involucrados:
• Nombre del departamento.
• Persona y datos de contacto.
• Participación requerida.
3. Descripción de los niveles de soporte necesarios:
• Niveles de soporte requeridos de los procesos
(incidentes, disponibilidad, capacidad, gestión
del cambio, gestión de presupuestos y costes de
servicios TI, etc.).
• Niveles de soporte requeridos a los
suministradores externos y a otros departamentos
de TI.
4. Planificaciones de trabajo:
• Objetivos y alcance.
• Planificación de trabajo de cada departamento,
y/o proceso, de TI (desarrollo de aplicaciones,
operación de servicio, etc.).
• Descripción de actividades.
• Cambios necesarios (descripción y justificación).
• Recursos necesarios.
• Estimación de esfuerzo y costes asociados.
Figura 5.14. Contenido tipo del plan de proyecto de creación del servicio
de las unidades externas a TI se realiza mediante los denominados “contratos de

soporte” (UC, Underpinning Contract).
Una vez confeccionada la propuesta de servicio, el SLA y el plan de proyecto del
servicio, la gestión de relaciones con el negocio tratará con el cliente los términos
finales para la provisión e implantación del servicio, dado que posiblemente el
cliente tenga que participar a lo largo de la creación del servicio (validaciones, prue-
bas, etc.).
Revisar y formalizar acuerdos internos (OLA)

El objetivo de esta actividad es formalizar los acuerdos de nivel operativo (véase el
apartado 6.1). Entre las distintas áreas y departamentos internos del proveedor de
TI involucrados en el soporte y operación del servicio una vez construido, y cuyas
características fueron acordadas e incluidas previamente en el SLA (de explota-
ción).
Esta formalización, que realiza el proceso de gestión de nivel de servicio, se plasma
en un documento en el que se recogen las características y condiciones del servicio
que se va a proveer por cada área.
Revisar y formalizar contratos externos (UC)

Esta actividad tiene como objetivo formalizar los contratos de servicio (UC) con
los diferentes suministradores externos a la organización de TI.
Su finalidad es la contratación de servicios a suministradores externos. Las caracte-
rísticas que de deben cumplir por los contratos de soporte se derivan del SLA, del
plan de proyecto del servicio y de los contratos ya existentes con los suministrado-
res. Estos acuerdos se formalizan en un contrato que recoge las características y
condiciones del servicio a prestar por cada suministrador.
Para la realización de esta actividad se deberán mantener reuniones con los distin-
tos suministradores con el fin de aclarar los requisitos, así como negociar las condi-
ciones para la realización de las actividades asociadas. Esta actividad la lleva a cabo
el proceso de gestión de suministradores con los requisitos establecidos por la ges-
tión de nivel de servicio (véase el apartado 6.1).
Confección de la solicitud de cambio (RFC) y aprobación

de creación del servicio
En este punto, el proceso de planificación e implementación de servicios confec-
ciona y tramita la solicitud de cambio (RFC, Request For Change) con la documen-
tación correspondiente para su revisión y aprobación formal por el proceso de ges-
tión del cambio (para profundizar en estos conceptos consulte el apartado 9.2),
que se realizará mediante el comité de cambios (CAB, Change Advisory Board), que
representa al proveedor de servicios de TI, y en el que tienen presencia todas las
partes implicadas. Cualquier cambio que afecte o pueda afectar a este proyecto será
analizado por este proceso para determinar si supone un impacto potencial en los
compromisos adquiridos con los clientes.
UNE-ISO/IEC 20000-1
La implementación de nuevos servicios o modificaciones en los existentes, inclu-

yendo la eliminación de un servicio, debe ser planificada y aprobada a través de un
proceso formal de gestión del cambio.
UNE-ISO/IEC 20000-2
Todas las modificaciones al servicio se c) la formación al usuario;

deberían reflejar en los registros de ges-
d) las comunicaciones sobre los cam-
tión del cambio:
bios;
Esto incluye a los planes para:
e) los cambios en la naturaleza de
a) la contratación y formación del la tecnología a la que se da
personal; soporte;
b) la reubicación; f) el cierre formal de los servicios.
A partir de este momento la petición de cambio aprobada se integra en la lista de cam-

bios planificados (FSC, Forward Schedule of Change). Este listado es una pieza funda-
mental en la actividad del proceso de gestión del cambio, ya que en él se controla toda
la actividad relevante de cambios en TI. Además, se genera un informe de disponibili-
dad prevista del servicio (PSA, Projected Service Availability). Las versiones actualizadas
de estos documentos deben estar a disposición de cualquier miembro de la organiza-
ción, por lo que, generalmente, se almacenan en la intranet de la compañía.
Construcción del servicio o de las modificaciones

Una vez aprobada la solicitud de cambio e introducido el proyecto en el listado
de cambios planificados (FSC), a través de la gestión del cambio, se da la orden de
comienzo de la construcción del servicio. Se inicia la ejecución de la planificación
del plan de proyecto por cada una de las áreas TI involucradas (desarrollo, infraes-
tructuras, proveedores externos, etc.) bajo la supervisión del proceso de planifica-
ción e implantación de servicios nuevos o modificados.
También, durante esta actividad, cualquier cambio al servicio y su plan de proyecto,

ya sea a petición del cliente o por necesidades internas de TI, deberá ser sometido
al análisis y aprobación a través del proceso de gestión del cambio.
En el transcurso de la construcción del servicio o de sus modificaciones, este pro-
ceso realizará el seguimiento y control de la etapa de construcción. Así, también se
responsabiliza del cumplimiento de plazos, calidad y costes, en esta etapa de cons-
trucción. Para realizarlo no se necesita duplicar funciones y se utilizarán las atribu-
ciones del equipo de gestión de proyectos o de desarrollo de la organización.
Como ya se ha mencionado, en la construcción se debería aplicar otro tipo de nor-
mativa o marcos de mejores prácticas (por ejemplo, SPICE, CMMI, PMBOK o
PRINCE2), que se integrarían con el proceso actual.
Integración y pruebas del servicio construido

Finalizada la etapa de construcción, se hace la recepción del desarrollo realizado,
verificando nuevamente el cumplimiento de todo lo especificado y se solicita apro-
bación al proceso de gestión del cambio para proceder a la implantación en los
entornos de integración y pruebas (previos al entorno productivo real).
En esta actividad es el proceso de gestión de la entrega quién es el responsable del
control y realización de las actividades (véase el capítulo 10). Como en otros casos,
se produce una doble responsabilidad y control, una derivada del proceso de crea-
ción de servicios, con foco en el ciclo completo de creación, y otra por parte de la
gestión de la entrega, cuya misión es realizar las actividades para la puesta en pro-
ducción de los cambios.
El resultado de esta etapa es un informe de pruebas del servicio, con los defectos
encontrados y su resolución.
En ITIL v3 hay dedicado un libro de buenas prácticas a la Transición del Servicio,
que arranca una vez finalizado el diseño del servicio (en este caso se considera el
servicio ya construido) y finaliza con el paso a producción. Este libro contiene acti-
vidades y directrices que se estructuran en cinco procesos: soporte y planificación
de la transición, gestión del cambio, activos y configuración del servicio, gestión de
la versión y del despliegue, validación y pruebas del servicio, y evaluación y la ges-
tión del conocimiento. Mientras que en ISO/IEC 20000 y en ITIL v2 todas las
actividades equivalentes a esta transición de ITIL v3 se agrupan en tres procesos:
gestión del cambio, gestión de la entrega y gestión de la configuración.
Aprobación de la implantación del servicio
UNE-ISO/IEC 20000-1
Los nuevos servicios, o las modificaciones en los existentes, deben ser aceptados por el
proveedor del servicio antes de ser implementados en el entorno de producción real.
Una vez finalizado el desarrollo y las pruebas del servicio, el proceso de gestión del
cambio toma el control para comprobar si se han cubierto todos los compromisos
reflejados en la RFC y someter a la aprobación del comité de cambios la implanta-
ción del servicio en el entorno de producción real.
La implantación del servicio en el entorno de producción real, la realiza el proceso
de gestión de la entrega (véase el apartado 10.1) bajo la supervisión de gestión del
cambio (véase el apartado 9.2).
Realización de la implantación y despliegue del servicio

Aprobada la implantación del servicio por la gestión del cambio, se procede a la
implantación en el entorno productivo real y despliegue del servicio. El despliegue
debe incluir también la formación a los usuarios, al service desk y al resto de los téc-
nicos de soporte. En esta actividad el proceso de gestión de la entrega es el respon-
sable del control y realización de estas actividades (véase el capítulo 10).
Comprobación resultados: revisión postimplantación
UNE-ISO/IEC 20000-1
Tras la implementación, el proveedor del servicio debe informar de los resultados

alcanzados por el servicio nuevo, o por el servicio modificado, comparándolos con los
previstos. Se debe realizar una revisión posterior a la implementación, que compare
los resultados reales con los planificados a través del proceso de gestión del cambio.
En la actividad de implantación la última actividad del proceso de gestión del cam-

bio es realizar una “revisión postimplantación” (PIR, Post Implementation Review)
para analizar los resultados reales obtenidos con la implantación realizada, compa-
rándolos con los resultados esperados. En esta actividad el proceso de gestión de la
entrega es quién se responsabiliza del control y realización de estas tareas (véase el

capítulo 10).
Esta revisión se debe realizar como mínimo en todos los cambios importantes de
TI y, por tanto, en la implantación de servicios nuevos o modificados. Si en esta
revisión se concluye que el cambio no tiene el efecto deseado, se decidirá si se da
marcha atrás para restaurar el estado inicial. Asimismo se revisarán y documenta-
rán las causas para evitar que vuelva a ocurrir otra vez.
El responsable de la planificación de nuevos servicios o de servicios modificados
debe tener una participación activa en la revisión postimplantación, ya que es el res-
ponsable final del resultado obtenido frente a relaciones con el negocio.
Tras esta actividad se cierra formalmente la RFC, comunicándolo al comité de cam-
bios, al responsable de gestión de niveles de servicio y al promotor de la RFC,
quien realizará las comprobaciones necesarias junto con el responsable de relacio-
nes con el negocio.
En este punto, y si las comprobaciones realizadas han resultado satisfactorias, el res-
ponsable de las relaciones con el negocio realizará las comunicaciones formales de
entrega del servicio al cliente.
Comunicación de los resultados a todas las partes

interesadas
Gestionado por el proceso de gestión de la entrega, se comunican los resultados y
la disponibilidad del servicio a las partes implicadas. El service desk centralizará la
comunicación a los usuarios, mientras que la gestión de relaciones con el negocio
lo hará con los clientes.
Cierre de la implantación y de la solicitud de servicio

Se procede al cierre de la implantación (cierre que ejecuta el proceso de gestión de
la entrega) y al cierre de la solicitud de servicio del cliente realizada por el proceso
de relaciones con el negocio.
Métricas del proceso

Es necesario elaborar información que permita evaluar si este proceso está cum-
pliendo con los objetivos previstos. Lo habitual es elaborar un conjunto de métricas
que permitan conocer los aspectos más importantes para cada organización. Muchas
de las métricas de este proceso son similares a la de los procesos que utiliza, por lo
que no se repiten aquí. Únicamente se enumeran aquéllas que tienen un carácter
más global al proceso:
• Número de proyectos realizados.
• El “Time to market” de los proyectos o plazo medio desde el primer contacto
con el usuario hasta que el servicio se ha entregado y se está utilizando.
• Cumplimiento de los plazos acordados o porcentaje de cumplimiento de los
plazos previstos en cada proyecto.
• Alineación con el cliente, medida como el número de inconformidades (o
modificaciones) del cliente por proyecto y del usuario final con los nuevos
servicios.
• Calidad técnica, medida como el número de defectos encontrados en las
pruebas del servicio.
• Número de incidentes causados por los nuevos servicios o las modificaciones.
• Cumplimiento de los costes acordados en los proyectos.
• Volumen medio de recursos utilizados. Número medio de horas/hombre
dedicados por proyecto.
• Calidad de las previsiones, medida como el número o coste de los nuevos
servicios no previstos en los planes anuales (porfolio de servicios, presu-
puestos, etc.).
Figura 5.15. Métricas relevantes para el proceso de creación de servicios

Siguiendo los principios de COBIT, las métricas se estructuran en tres capas: una
primera capa con las métricas que aportan una visión al negocio de cómo está TI,
denominadas KGI de TI (KGI, Key Global Indicador); una segunda capa destinada
a la visión que el director de sistemas de información debería tener sobre el pro-
ceso, denominadas KGI del proceso. Por último, para mostrar los detalles internos
del proceso al responsable del proceso estaría la tercera capa, los KPI del proceso
(KPI, Key Performance Indicador).
En el gráfico de la figura 5.15 se muestra un resumen de los indicadores más rele-
vantes de este proceso.
Roles participantes en el proceso

Los roles involucrados en el proceso se estructuran en: los roles propios del pro-
ceso y los roles ajenos al proceso.
Los roles propios del proceso son:
• El gestor de la creación de servicios (gestor del proceso o process mana-
ger), que es el responsable del día a día de la actividad del proceso, en este
caso supervisa cada proyecto desde su concepción hasta su entrega defini-
tiva, supervisa a los responsables de proyectos en el cumplimiento de lo
establecido en el proceso, detecta y propone mejoras en su proceso y en
otras áreas de TI relacionadas, etc.
• Los administradores o personal de soporte al proceso, es el personal que
ayuda al gestor en el control de toda la actividad.
• Los responsables o jefes de proyecto, que se responsabilizan de un proyecto
desde su inicio hasta su fin.
• Los especialistas en tecnologías, aplicaciones y formación, que realizan el
diseño técnico y funcional, realizan las pruebas técnicas y funcionales, reali-
zan la implantación y despliegue y realizan la formación a los usuarios sobre
los nuevos servicios.
• Los roles típicos del desarrollo de aplicaciones (analistas funcionales, progra-
madores, etc.).
Los roles ajenos relevantes en este proceso son:

• El responsable de relaciones con el negocio, que es la cara visible de la orga-
nización de TI con el cliente, tiene como cometido la gestión de las relacio-
nes del cliente con el proveedor de servicios TI.
• El responsable de la gestión del servicio, que vela por que todos los servicios
cumplan los niveles pactados.
• El propietario del modelo SGSTI, que actúa como propietario del proceso
(process owner), define el proceso y se encarga de la mejora continua del
mismo. Todo ello de una forma integrada con el modelo de gestión de TI
incorporado en el SGSTI.
• El responsable de la gestión del cambio, ya que debe autorizar el inicio de las
pruebas e integración, la implantación en producción y el cierre de la entrega.
Los roles de mayor relevancia que participan en el proceso se representan en el grá-

fico de la figura 5.16.
Roles del proceso
Responsable de la
SGSTI
Gestor de la
creación de servicios
Administrador y
soporte del proceso
Propietario del
modelo (SGSTI)
Especialistas en el Especialistas Especialistas

Gestor del cambio
diseño del servicio de desarrollo técnicos
Figura 5.16. Roles del proceso de creación de servicios

Resumen
La creación de servicios se ha convertido en un factor clave para lograr el éxito
empresarial. El proveedor de TI debe posibilitar un tiempo de entrega de servicios
(time-to-market) acorde a las necesidades del cliente, pero también debe contemplar
que los costes, la funcionalidad y calidad de los servicios estén ajustados a sus nece-
sidades reales.
Las principales responsabilidades que tiene a su cargo el proceso se indican en la
figura 5.17.
Figura 5.17. Principales responsabilidades del proceso
Además, el proceso realiza dos aportaciones fundamentales a la gestión de servicios

de TI:
• Organiza todo el ciclo de creación de servicios para que se “fabriquen” en los
plazos acordados, con la calidad, costes y funcionalidad pactados.
• Asume la responsabilidad de coordinar a todos los procesos y departamentos
de TI para lograr sus objetivos.
Para ello, articula un ciclo de la provisión de servicios que involucra y gestiona

todos los procesos, funciones y áreas de TI implicados. Elabora un plan de trabajo
integrado para proveer e implantar el servicio a partir del cual se negocia con el
cliente. Una vez que se ha logrado un consenso y acuerdo con el cliente, se aprueba
formalmente el plan de proyecto mediante el proceso de gestión del cambio y su
órgano de gestión interno, el comité de cambios, en el que están representadas
todas las partes implicadas.
En la figura 5.18 se muestra un resumen general de las actividades de este proceso.
Resumen del ciclo de “fabricación” de un servicio de TI
1. Identificar las necesidades del cliente y proponer servicios TI que

satisfagan dichas necesidades.
2. Documentar los requisitos que debe cumplir el servicio solicitado por el
cliente. El resultado de esta actividad: Requisitos de nivel de servicio (SLR).
3. Realizar un análisis de viabilidad (si procede).
4. Elaborar las especificaciones técnicas del servicio.
5. Elaborar la propuesta de servicio incluyendo la propuesta de SLA para ser
presentado y negociado con el cliente.
6. Negociar y acordar con el cliente la propuesta de servicio y SLA final.
Solo se tratan los aspectos de cliente y en términos de negocio.
7. Elaborar el plan de proyecto del servicio con todos los procesos y
departamentos TI implicados.
8. Revisión de acuerdos internos (OLA) y externos (UC).
9. Crear RFC y presentar a gestión de cambio para su aprobación,
formalización y compromiso de realización de todas las partes implicadas.
10. Inclusión del proyecto en la planificación de cambios (FSC), a partir de la
cual se gestiona cualquier cambio, propio o provocado por otros motivos,
de forma integrada y normalizada.
11. Control del proceso de fabricación del servicio realizado por cada uno de
los intervinientes.
12. Aprobación de la implantación del servicio.
13. Gestión de la entrega del servicio al cliente y revisión posimplantación.
14. Comprobación resultados de la implantación del servicio comparando los
resultados reales obtenidos con los planificados.
15. Comunicación de resultados.
16. Cierre de la petición.
Figura 5.18. Resumen del ciclo de fabricación de un servicio de TI
Este proceso de planificación e implementación es el punto central sobre el que se

sustenta la coordinación dentro del proveedor de servicios TI para la creación y evo-
lución de los servicios a los clientes. Esta actividad la realiza con la colaboración de
múltiples intervinientes coordinándolos en la búsqueda de encontrar el equilibrio
correcto entre la demanda del cliente, la provisión del servicio, el coste de los mis-
mos y la satisfacción del cliente.
Para finalizar este capítulo, es importante destacar que este proceso es complejo y
soporta múltiples relaciones, por lo que el uso de las herramientas adecuadas es un
punto que no se debe descuidar. La disponibilidad de herramientas específicas (catá-
logo de servicios actualizado, formularios de recogida de requerimientos y especifi-
caciones SLR, SS, modelos de SLA/OLA/UC, un sistema de gestión documental,
etc.) pueden ser el elemento clave para el éxito de este proceso y, por tanto, para el
éxito de TI en la provisión de servicios nuevos o modificados.
Beneficios
La planificación e implementación de servicios nuevos o de servicios modificados
posibilita una mayor confianza en la relación TI-Negocio, y un incremento de
la satisfacción de los clientes, gracias a la transparencia y claridad de las propuestas
de los servicios que se van a proveer e implantar, ya que están realizadas con el
compromiso de todas las partes implicadas y alineadas con las necesidades de nego-
cio planteadas por el cliente.
También contribuye a mejorar esta relación la fiabilidad que proporciona la planifi-
cación integrada de todas las áreas y procesos TI intervinientes que permite asegu-
rar que una petición es viable, que la relación calidad-precio es adecuada, que está
alineada con la estrategia de negocio y técnica. También contribuye a agilizar y ase-
gurar el time to market de provisión de soluciones, minimizando los riesgos relacio-
nados con el cumplimiento de plazos y costes asociados.
Los principales beneficios que se obtienen al implementar este proceso son:
• Los servicios TI se diseñan para satisfacer las necesidades reales del cliente.
• La relación con el cliente se basa en “servicios” que TI proporciona, y en el
lenguaje y términos del negocio.
• Se atienden las demandas del negocio convirtiéndolas en servicios, de acuerdo
con la estrategia y los presupuestos.
• La organización de TI y sus clientes tienen unas expectativas claras y consis-
tentes del servicio solicitado a TI.
• Gestión formalizada de los requisitos del cliente, en su propio lenguaje.
• Control del ciclo completo, e integrado, de creación y modificación de los
servicios, desde la perspectiva de las necesidades y acuerdos con el cliente,
hasta su entrega y puesta en funcionamiento operativo.
• La organización del proveedor de TI tiene una visión integrada de lo que el

cliente espera de ellos y dirige sus esfuerzos a las áreas y compromisos clave
para el negocio.
• Aseguramiento de calidad del servicio acorde a lo estipulado con el cliente.
• Mejora del cumplimiento de los plazos de entrega de servicios, nuevos o evo-
lucionados, al cliente.
• Gestión de los costes del proyecto acordes a lo estipulado con del cliente.
• Controla que el servicio se ha realizado siguiendo las políticas y estándares
de la organización TI, lo que facilita su posterior evolución de forma efi-
ciente.
• ¿Cuál es la operativa habitual para la creación de servicios TI en su
organización?
• ¿Cómo se validan las propuestas de nuevos servicios?
• ¿Qué mejoras incorporaría al proceso propuesto en este capítulo?
1
6 Procesos de
provisión de servicio
Capítulo 6
6.4. Elaboración de presupuestos

6.1. Gestión de nivel de servicio y contabilidad de los
servicios de TI
6.2. Generación de informes

6.5. Gestión de la capacidad
del servicio
99,99%
6.3. Gestión de la continuidad y 6.6. Gestión de la seguridad
disponibilidad del servicio de la información


6. Procesos de provisión de servicio 193
Una vez creado el servicio y puesto con éxito en explotación regular, es necesario
desencadenar una serie de actividades que ayuden a garantizar que los servicios cum-
plen los cometidos pactados con el negocio en términos de: los niveles de servicio,
la continuidad, la disponibilidad, los presupuestos, la capacidad y la seguridad.
Además de velar por la consecución de lo comprometido, también se debe estar
involucrado en asegurarse que los nuevos servicios o la evolución de los mismos se
realiza cumpliendo con lo que la organización ha predefinido.
Para garantizar que se cumplen estos objetivos se han definido los procesos de
provisión del servicio, seis procesos especializados que engranan con las relacio-
nes con el negocio y con la creación de servicios. En la figura 6.1 se muestran
estas relaciones.
Planificación e implementación de nuevos servicios

o de servicios modificados
Procesos de provisión del servicio

Relaciones
con el
negocio Presupuesto y contabilidad
Gestión de la capacidad
Gestión
de nivel de
servicio
Gestión de la continuidad y
disponibilidad de servicios TI
Generación Gestión de la seguridad

de informes de la información
del servicio
Figura 6.1. Procesos de provisión del servicio y su ámbito de relación
En este escenario de servicios de alta calidad, alineados con los objetivos del nego-
cio, que cubren las necesidades actuales y que deben ser capaces de evolucionar
rápidamente para cubrir las necesidades futuras, los procesos de la provisión del
servicio toman una especial importancia.
Los procesos de provisión del servicio en ISO/IEC 20000 contienen una impor-
tante diferencia frente a lo definido en ITIL v2, pues incorpora la generación de
informes de servicio como un proceso independiente e incluye también el proceso
de seguridad de la información. Además, agrupa en uno sólo los procesos de conti-
nuidad y de disponibilidad (que en ITIL v2 están separados).
6. Procesos de provisión de servicio
6.1. Gestión de nivel de servicio 195
6.1. Gestión de nivel de servicio
Figura 6.1.1. Esquema general del proceso de la gestión de nivel de servicio
En el capítulo anterior se ha podido apreciar que la gestión de nivel de servicio

desempeña uno de los papeles clave en la creación y evolución de los servicios de
TI, definiendo y acordando los niveles de servicio que se deben cumplir. Pero este
proceso también desempeña funciones importantes durante la prestación habitual
de los servicios de TI, registrando y gestionando el cumplimiento de los niveles de
servicio comprometidos. Por ello, este proceso está considerado como una pieza
esencial para garantizar la orientación al cliente de los servicios.
Así, la misión principal de la gestión de nivel de servicio es establecer los niveles
de servicio a los que TI se puede comprometer, para posteriormente velar por su
consecución. Además, contribuye a la mejora de la calidad de los servicios apli-
cando un ciclo continuo de seguimiento, medición, generación de informes y aná-
lisis de los resultados. También propone acciones de mejora que permitan erradicar
las deficiencias en la prestación de los servicios, mejoras siempre alineadas con las
necesidades del negocio y con un coste asociado justificado.
Por tanto, este proceso es la médula espinal que distribuye a todas las áreas de TI
las necesidades de los clientes en formato de niveles de servicio. Participa activa-
mente en el ciclo de creación de los servicios, y es el responsable de controlar el
cumplimiento de estas necesidades a lo largo de la vida productiva de los mismos.

Supervisa si se está consiguiendo el nivel de servicio acordado y, en caso contrario,
determina el motivo y promueve las acciones de mejora adecuadas.
El seguimiento continuo de los niveles de servicio permite mejorar la calidad del
servicio de TI y eliminar las deficiencias en los mismos, reduciendo el impacto
negativo en el negocio.
Pero, el beneficio más significativo de una efectiva gestión de nivel de servicio es
la mejora de la relación y la confianza de los clientes con su proveedor de servicios
de TI.
En ITIL v2 hay definido un proceso con el mismo nombre, pero en realidad las
funciones asignadas en ITIL a este proceso le convierten en un megaproceso, el
gestor del nivel de servicio debe ser un “superhombre”. Así, ITIL v2 agrupa en la
gestión de nivel de servicio actividades que en ISO/IEC 20000 se han distribuido
en 5 procesos, en:
• El presente proceso de gestión de nivel de servicio (véase el apartado 6.1 de
las normas).
• El proceso de generación de informes del servicio (véase el apartado 6.2
de las normas).
• El proceso de relaciones con el negocio, el definido en estas normas se
corresponde únicamente a las relaciones con el cliente, que se llevan a
cabo en la gestión de nivel de servicio de ITIL (véase el apartado 7.2 de
las normas).
• El proceso de gestión de suministradores, pues la gestión de nivel de servicio
de ITIL v2 también se responsabiliza de la definición de los niveles de servi-
cio a contratar a terceros (UC, Underpinning Contract) y del seguimiento
posterior de su cumplimiento (véase el apartado 7.3 de las normas).
• El proceso de planificación e implementación de nuevos servicios o de servi-
cios modificados (véase el capítulo 5 de las normas).
Analizando ITIL v3, se aprecia que aparecen la gestión del catálogo de servicios y
la gestión de suministradores como procesos nuevos que restan peso a la gestión
de nivel de servicio definida esta nueva versión de ITIL.
Por tanto, el panorama entre estos tres modelos queda algo intrincado. En la figura
6.1.2 se muestra una comparativa entre los alcances asignados a este proceso en los
diferentes marcos.
Proceso en ITIL v2 Proceso en ITIL v3 Procesos en ISO/IEC 20000
• Gestión de nivel de • Gestión de nivel de servicio (SLA)

servicio ITIL v3
• Generación de informes del servicio
• Gestión del catálogo
• Gestión relación con el negocio
• Gestión de nivel de servicio
de servicio ITIL v2 • Planificación e implementación de
• Gestión de
servicios nuevos o modificados
suministradores
(sólo niveles de servicio • Gestión de suministradores (sólo niveles
contratados) de servicio contratados)
Figura 6.1.2. Comparativa del alcance de la gestión de nivel de servicio

entre los diferentes marcos
En la figura 6.1.3 se presenta una introducción al proceso.
Proceso de gestión de Qué aporta:

nivel de servicio • Fijación de los objetivos de los
servicios mediante parámetros
medibles.
Definición: • Confianza de que los niveles de
Proceso que se encarga de mantener y servicio acordados se pueden cumplir.
mejorar la calidad de los servicios TI • Conocimiento preciso del esfuerzo
mediante una gestión eficiente de los que le supone a TI alcanzar unos
acuerdos de nivel de servicio firmados determinados niveles de servicio.
con los clientes. • Los servicios de TI se conciben para
alcanzar las expectativas del cliente.
• El desempeño del servicio se puede
Objetivo: medir, por lo tanto se puede gestionar
Definir, acordar, registrar y gestionar y mejorar.
los niveles de servicio. • Se mejora la relación interna entre
unidades de TI y con los proveedores,
en base a acuerdos medibles.
• Contribuye a la mejora de la
satisfacción de los clientes.
Figura 6.1.3. Introducción al proceso de gestión de nivel de servicio
El proceso debe ser capaz de comprender las demandas del negocio, aunque en
ISO/IEC 20000 no lleva propiamente las relaciones con el negocio (véase el apar-
tado 7.2). Se relaciona internamente con el resto de unidades de TI para negociar y
fijar los acuerdos operativos. También establece los requisitos para que los contra-
tos de soporte con los suministradores estén alineados con los compromisos del
servicio, contratos que negociará y seguirá el proceso de gestión de suministrado-
res (véase el apartado 7.3).
En la figura 6.1.4 se muestran los principios básicos en los que se sustenta la activi-
dad de este proceso.
Figura 6.1.4. Principios básicos del proceso
La implementación de las Normas ISO/IEC 20000 requiere un cambio en la cul-

tura de la organización, con una orientación al servicio y al cliente. La gestión de
nivel de servicio es el instrumento principal para inculcar la cultura de servicios en
la organización de TI. Así, la misión de la organización de TI va más allá de la pura
tecnología, para ofrecer soluciones al negocio empaquetadas bajo el concepto de
servicio. Para ello, el catálogo de servicios y los acuerdos de nivel de servicio (SLA)
son las principales palancas para esta transformación cultural. Los servicios que se
ofrecen a los clientes se recogen en un catálogo de servicios de TI, alineado con el
negocio, que gestiona y mantiene este proceso. Además, los servicios llevan asocia-
dos un compromiso de prestación negociado con los clientes, incluidos en los
acuerdos de nivel de servicio o SLA. Este compromiso lo expande internamente

hacia toda la organización de TI y externamente hacia los suministradores que par-
ticipan en el soporte de los servicios.
Otra de las misiones del proceso es inculcar el rigor en toda la organización en rela-
ción al cumplimiento de los acuerdos firmados, para lo cual realiza una monitori-
zación y seguimiento permanente.
El proceso de gestión de nivel de servicio debe establecer e implantar un sistema de
seguimiento y medición para identificar si se están logrando los niveles de servicio
acordados con los clientes. En caso contrario, debe determinar y analizar, con los
procesos y áreas relacionadas, el motivo de esta ineficiencia para promover las accio-
nes de mejora necesarias. Además, establece un plan de mejora continua de los
servicios que se incorporará al plan de mejora unificado (véase el apartado 4.1), en
todos sus aspectos: técnicos, organizativos, de formación, de documentación, etc.
Como en el resto de los procesos en ISO/IEC 20000, la gestión de nivel de servi-
cio mantiene también una actividad de mejora continua de su propia actividad
como proceso.
La misión principal de la gestión de nivel de servicio es mantener y mejorar la cali-
dad de los servicios de TI. En la figura 6.1.5 se muestran los principales conceptos
que se desarrollan en este proceso.
Acuerdo de nivel de servicio (SLA, Service Level Agreement). Es un documento

que recoge los compromisos acordados entre el cliente y el proveedor de servicios
de TI relativos a las condiciones de prestación o explotación del servicio requerido.
Este documento es un acuerdo por escrito que define el alcance concreto del servi-
cio, los objetivos que se deben cumplir y las responsabilidades de ambas partes. Por
tanto, el SLA es el “contrato” de prestación de uno o varios servicios del catálogo a
los clientes y sus usuarios. El SLA detalla la particularización en la prestación de un
servicio del catálogo a un cliente.
El proveedor de servicios y el cliente deberían desarrollar una asociación transpa-
rente, a fin de poder alcanzar unos acuerdos beneficiosos para ambas partes; de
otro modo, el SLA perdería rápidamente su reputación y se podría caer en el típico
intercambio permanente de acusaciones que no es un buen medio para conseguir
ninguna mejora de la calidad del servicio.
Acuerdo de nivel operativo (OLA, Operacional Level Agreement). Documento

que formaliza un acuerdo de colaboración entre departamentos internos de la orga-
nización de TI para la prestación y operación regular de los servicios. Se trata, por
tanto, de un contrato interno en TI.
Catálogo
de servicios Supervisión
Cultura del servicio
de servicio y de los SLA
Mejoras
Acuerdos de nivel
de servicio (SLA)
Programa de
mejora del
Acuerdos de nivel Gestión de nivel servicio (SIP)
de operativo (OLA) de servicio
Cultura de
compromiso
Requisitos para PDCA

los contratos Mejoras SGSTI
de soporte (UC)
Mejora
del proceso
Figura 6.1.5. Principales componentes del proceso de gestión

de nivel de servicio
Catálogo de servicios (service catalog). Documento o base de datos que elabora

la organización de TI para informar a clientes, usuarios y personal de TI de los
servicios ofrecidos. Proporciona una visión sencilla, en terminología entendible por
el negocio, de todos los servicios de TI y las alternativas u opciones de prestación.
Es recomendable que refleje los precios de los servicios en el caso de que se impu-
ten, o por lo menos de los costes en los que incurre la empresa al proveerlos. El
catálogo tiene una información visible por el negocio y otra parte destinada al uso
interno de TI, en la que se describen en más detalle los elementos técnicos que son
necesarios para la prestación del servicio.
Contrato de soporte (UC, Underpinning Contract). Documento contractual

(contrato legal) entre el proveedor de TI y un suministrador de servicios externo.
Este contrato define los objetivos, alcance y características del servicio que se va a
prestar, así como los plazos y costes asociados.
Cultura de compromiso. La organización de TI y sus miembros articulan sus

objetivos y su actividad encaminada principalmente al cumplimiento de los acuerdos.
Cultura de servicio. Implica que la satisfacción del cliente es la prioridad principal

para todos los miembros de la organización de TI que ofrece los servicios. Además,
se controla que las actividades llevadas a cabo en la provisión de los servicios con-
tribuyen a los objetivos de negocio del cliente.
Programa de mejora del servicio (SIP, Service Improvement Program). Docu-

mento que describe las áreas de mejora de un servicio y define el plan de proyecto
a realizar por cada área o proceso de la organización de TI para llevar a cabo las
mejoras propuestas. Este documento, por tanto, establece el objetivo y alcance de
las mejoras, su justificación en términos de coste/beneficio, las fases, actividades,
planificación y responsabilidades, así como, las métricas necesarias para el segui-
miento del proyecto y validación de las mejoras.
Servicio de TI. Se puede definir como un conjunto de funciones relacionadas, pro-

porcionadas por sistemas de TI que dan soporte a una o más áreas de negocio
(departamentos, sucursales, etc.). Un servicio suele estar compuesto de partes: soft-
ware, hardware, elementos de comunicación soporte, etc., pero el cliente y el usua-
rio final que lo utiliza, lo perciben como algo autocontenido y coherente.
Otra posible definición podría ser “un conjunto integrado por una serie de elemen-
tos incluyendo procesos de gestión, hardware, software, facilidades y recursos huma-
nos, que constituyen una capacidad que permite satisfacer una necesidad o alcanzar
un determinado objetivo”.
En ITIL v3, un servicio se define como “un medio de entregar valor a los clientes
facilitando los resultados que los clientes quieren lograr sin la necesidad de que
tengan la propiedad de los activos necesarios, ni la responsabilidad de los riesgos
asociados”.

La gestión de nivel de servicio se organiza en torno a tres áreas de actividad: una
enfocada al establecimiento de los acuerdos de nivel de servicio con los clientes,
otra enfocada a que TI cumpla los compromisos adquiridos en los SLA y, la
última, destinada a la mejora de los servicios. La primera de ellas está desencade-
nada por el proceso de gestión de las relaciones con el negocio a raíz de una solici-
tud de un cliente de un nuevo servicio, una modificación a uno existente o una
propuesta de cambio a un SLA ya establecido. En este caso, la responsabilidad del
presente proceso es todo lo relativo a los niveles de servicio, a definir o ya defini-

dos. Las otras dos áreas restantes se desempeñan de forma continua y velan por la
calidad de los servicios prestados y por el cumplimiento de los SLA firmados.
Las actividades el proceso junto con sus entradas y salidas se resumen en la figu-
ra 6.1.6.
Desencadenantes 3 Gestión del catálogo de Salidas principales:

del proceso: servicios: creación y Ü Catalogo de servicios.
Ü Necesidades negocio y mantenimiento.
Ü Acuerdos de nivel de
clientes. 3 Gestión de los SLA: creación, servicio (SLA).
Ü Sistema de acuerdo, difusión,
Ü Programa de mejora del
monitorización de mantenimiento.
servicio (SIP).
servicios. 3 Gestión de OLA y respaldo
Ü Encuestas de mediante UC. Salidas secundarias:
satisfacción del cliente. 3 Supervisión y monitorización Ü Acuerdos nivel operativo
de los servicios y de (OLA).
Entradas de soporte: los SLA.
Ü Requisitos para
Ü Catálogo de servicios 3 Mejorar los servicios y SIP, los contratos de
existente. a través de los programas soporte (UC).
Ü Acuerdos de nivel de de mejora del servicio.
Ü Especificaciones para los
servicio existentes. 3 Supervisión y mejora del informes de cumplimiento
Ü Acuerdos nivel operativo proceso. de nivel de servicio.
y contratos de soporte 3 Generación de peticiones de Ü Plan de mejora del
existentes. cambio (RFC): del catálogo, proceso.
Ü Información del nivel de de SLA, de UC, de los
Ü Peticiones de cambio
servicio procedente servicios o del propio proceso.
(RFC) por SLA o SIP.
de otros procesos.
Ü CMDB actualizada.
Ü Políticas negocio y TI.
Ü Arquitecturas TI.
Ü CMDB.
Figura 6.1.6. Entradas, actividades y salidas del proceso de gestión

Las entradas que desencadenan la activación del proceso de creación de servicios

son la resolución de las necesidades del cliente (tratada por el proceso de gestión de
las relaciones con el negocio); la información sobre el desempeño de los servicios
recibida de los sistemas de monitorización, especialmente en relación al cumpli-

miento de los SLA; los resultados negativos de las encuestas de satisfacción del
cliente o del usuario que impulsen a los gestores de nivel de servicio al impulso de
acciones de mejora.
El proceso utiliza otras entradas de apoyo a la realización de sus actividades. Las
principales entradas de soporte son el catálogo de servicios existente para determi-
nar si la necesidad del cliente está cubierta por el catálogo o para realizar modifica-
ciones en él; los SLA, OLA y UC existentes como base para la definición de los
nuevos o para modificarlos; la información sobre el nivel de servicio y propuestas
de mejora provenientes de otros procesos o áreas; las políticas relativas a la presta-
ción de servicios; las arquitecturas de TI existentes con el fin de conocer los niveles
de servicio a los que se puede comprometer; y la CMDB para proveer todo tipo de
información sobre TI y sus elementos de configuración.
El proceso de gestión de nivel de servicio agrupa las actividades de coordinación,
diseño, negociación, monitorización y reporte de los acuerdos del nivel de servicio
establecidos con el cliente, así como la revisión continua de los resultados del servi-
cio para asegurarse de mantener y mejorar gradualmente la calidad del servicio, que
necesita el negocio, de forma justificable en términos de coste. Las actividades prin-
cipales que realiza este proceso son:
• Gestión del catálogo de servicios. Se encarga de la creación y manteni-
miento del catálogo de servicios de TI. Ayuda al proceso de relaciones con el
negocio a determinar si las necesidades del cliente pueden ser provistas por
servicios del catálogo.
• Gestión de SLA. Creación de los acuerdos de nivel de servicio (SLA), rea-
lizada en coordinación o bajo petición de relaciones con el negocio. Difu-
sión de los SLA entre toda la organización de TI. Mantenimiento de los
SLA, actualizando sus contenidos en coordinación con relaciones con el
negocio.
• Gestión de OLA y respaldo con UC. Revisión de los acuerdos internos y
contratos con suministradores (OLA y UC) para garantizar que respaldan lo
comprometido en los SLA. En relación a los UC, pasa los requisitos que se
deben cumplir al proceso de gestión de suministradores para la realización
de un nuevo contrato o la modificación a los existentes.
• Supervisión y monitorización de los servicios y de los SLA. Para verificar
el cumplimiento de los niveles de servicio y emprender acciones de mejora
en caso de necesidad.
• Mejora de los servicios y SIP. Creando un programa de mejora del servi-
cio para cada uno de ellos, o bien, uno conjunto.
• Supervisión y mejora del funcionamiento del proceso de gestión de

nivel de servicio.
• Generación de las solicitudes de cambio (RFC). Necesarias para la modi-
ficación o ampliación del catálogo de servicios, para los nuevos o modifica-
ciones a los SLA y los OLA, y para la aprobación y ejecución del programa
de mejora del servicio (SIP) o el plan de mejora del proceso.
Las salidas principales del proceso son el catálogo de servicios creado, actualizado y
publicado a los usuarios (vía web); los acuerdos de nivel de servicio nuevos o
actualizados firmados; el o los programas de mejora del servicio, que se remitirán
al comité de cambios (CAB) y al plan de mejora unificado de los procesos y de los
servicios (véase el capítulo 4).
Las salidas secundarias del proceso son los acuerdos de nivel operativo internos
nuevos o actualizados; la definición de requisitos para los contratos de soporte para
la gestión de suministradores; las especificaciones sobre los contenidos necesarios
sobre los informes de los servicios, tanto para el uso interno del proceso, como para
su publicación al resto de TI y al cliente; las peticiones de cambio necesarias para la
aprobación de las modificaciones a realizar; y por último, la CMDB actualizada con
los cambios en el catálogo, en los SLA, etc.
El catálogo de servicios de TI
El catálogo de servicios es el instrumento de relación más importante de TI con sus
clientes, ya que en él se recoge el conjunto total de los servicios que la organización
de TI provee a sus clientes. El catálogo es una excelente herramienta para ayudar
en el cambio cultural del proveedor de servicios de TI hacia objetivos como:
• Alineamiento con el negocio. Aportando valor añadido al conocer de
forma clara y precisa los servicios de TI que soportan su negocio.
• Orientación al cliente. Estructurando la misión y el trabajo de TI en torno
a la satisfacción de las necesidades del cliente en forma de prestación de
servicios.
• Calidad de servicio. Contemplando los indicadores y métricas que consti-
tuyen la base de los acuerdos de nivel de servicio (SLA).
• Gestión de los servicios. Facilita la gestión y control de los niveles de servi-
cio comprometidos con los clientes, posibilitando medir en términos que el
cliente entiende. Estas medidas permiten pasar de medir “percepciones” a
tener métricas entendidas y acordadas por las dos partes.
UNE-ISO/IEC 20000-1
Se deben acordar por las partes, y registrar, el conjunto total de los servicios a ser
provistos, junto a los correspondientes objetivos de nivel de servicio y las característi-
cas de la carga de trabajo que deben soportar.
UNE-ISO/IEC 20000-2
Catálogo de servicios a) el nombre del servicio,
Todos los servicios deberían estar defini- b) los objetivos (por ejemplo tiempo de res-
puesta o de instalación de una impre-
dos en un catálogo de servicios. Este sora, tiempo para reiniciar un servicio
catálogo puede ser referenciado desde tras un fallo importante),
el SLA y debería utilizarse para recoger c) datos de contacto,
aquellos aspectos considerados como d) horario del servicio y excepciones,
demasiado cambiantes para ser intro- e) disposiciones de seguridad.
ducidos en el SLA.
El catálogo de servicios es un docu-
El catálogo de servicios debería ser mento clave para establecer las expec-
mantenido y estar actualizado en todo tativas del cliente y debería ser fácil-
momento. mente accesible y estar ampliamente
Nota: El catálogo de servicios puede incluir infor- disponible tanto para los clientes como
mación genérica como: para el personal de apoyo.
La característica más importante del catálogo es que constituye el único punto de

información sobre la oferta de servicios, de interés tanto para el cliente, como para
la propia organización de TI. En el catálogo se deja bien claro lo que TI ofrece a la
comunidad de clientes y usuarios.
El catálogo de servicios se construye con los siguientes propósitos:
• Presentar a los clientes y usuarios los servicios existentes de una forma orga-
nizada que permita conocer las funcionalidades y requisitos de los servicios,
así como, servir de base para futuras negociaciones de acuerdos del nivel de
servicio.
• Definir y organizar los servicios internos de infraestructura, que TI presta a
un nivel interno no perceptible por el cliente, pero que son necesarios para
sustentar los servicios prestados a los clientes.
• El catálogo de servicios está dirigido a cualquier cliente y usuario que soli-
cite información de los servicios que presta el proveedor de servicios de TI.
• Facilitar que la organización de TI gestione los servicios de una forma efi-

ciente, ya que el catálogo está elaborado por y para los clientes y contiene los
niveles de servicio acordados.
Para cumplir su función, se debería acceder a él fácilmente y estar disponible tanto

para los clientes como para el personal de TI. La publicación vía web en un portal
de TI en la intranet de la empresa es uno de los mejores medios para conseguirlo.
Además se deben preparar sesiones de presentación del catálogo, tanto con los
clientes, como internamente en TI.
El catálogo debe contener todos los servicios que proporciona TI, sus característi-
cas, y los clientes y usuarios a los que van destinados.
En la actividad de definición de un catálogo de servicios TI se suelen utilizar los
siguientes elementos:
• Definición de servicio. Explicación precisa de lo que es un servicio.
• Clasificación en categorías y subcategorías de servicio. Agrupación lógica de
servicios. Los servicios se pueden organizar realizando agrupaciones con dis-
tintos grupos de servicios.
• Lista de servicios. Enumeración de todos los servicios agrupados por cate-
goría/subcategoría.
• Estructura del catálogo. Índice general del contenido que tendrá el catálogo.
• Plantilla de la ficha de un servicio. Estructura del documento que describirá
cada servicio.
• Fichas descriptivas de los servicios. Documentos elaborados para cada uno
de los servicios que reflejan la oferta común de TI. Contienen la descripción,
atributos, parámetros y componentes de cada servicio ofertado. Una defini-
ción estándar de un servicio, puede adaptarse a las necesidades de un cliente
a través de la firma de un SLA específico con este cliente.
• Relación de áreas cliente. Clasificación de los clientes de TI a los que se ofre-
cen servicios. Pueden ser clientes internos (de la misma empresa) o externos.
• Mapa de cliente/categorías de servicio. Esquema gráfico de las categorías de
servicios y sus áreas cliente.
• Matriz cliente/servicio. Tabla que relaciona cada servicio con sus áreas
cliente.
La estructura habitual de un catálogo de servicios se muestra en la figura 6.1.7.

Estructura de catálogo de servicios.

Plan de proyecto de creación del servicio
1. Definición y objetivos del catálogo de servicios:

2. Introducción. Contiene una breve descripción de la
organización de TI. Incluir número de empleados,
cuánto tiempo lleva en la empresa, misión y visión,
y persona de contacto del catálogo (suele ser un
gestor de clientes).
3. Categorización de servicios y mapa de servicios.
Explica la clasificación de los servicios definida.
4. Lista y descripción de servicios. Incluir links a las
fichas de servicios que contengan la descripción de
los servicios.
5. Glosario. Definición de los conceptos generales más
importantes (SLA, etc.).
6. Anexos. Incluir la información necesaria que no esté
recogida en los capítulos anteriores y links a los
siguientes documentos: matriz cliente/servicio,
plantilla de la ficha de servicio, ejemplo de SLA, etc.
Figura 6.1.7. Estructura tipo de un catálogo de servicios
Con el fin de describir de forma detallada y homogénea todos los servicios que
oferta TI, se debe establecer una plantilla documental que servirá de base para defi-
nir todos los servicios. Esta ficha tipo suele estructurarse en dos partes: una que
contiene los aspectos de interés para los clientes y usuarios, y otra que incorpora
detalles sobre los servicios internos de TI, que no se muestra a los usuarios. En la
figura 6.1.8 se presenta un ejemplo de la estructura de una ficha de servicio.
Es recomendable que el servicio se dé de alta en el catálogo tan pronto como se
conozcan los datos básicos del mismo, sin esperar a que esté operativo. De esta
forma, toda la comunidad de usuarios y los profesionales de la organización de TI
conocerán de primera mano los servicios que están en fase de definición y acuerdo.
Para gestionar correctamente las expectativas y no crear conflictos o malos entendi-
dos, se utiliza la información de estado del servicio (véase la figura 6.1.9). Esta
información debe contener las etapas del ciclo de vida de los servicios, desde su
petición hasta su retirada de la operación.
• Definición.
• Funcionalidades del servicio.
Ficha de un servicio de TI • Opciones de contratación.
• Condiciones de uso.
Información externa del servicio: • Ámbito del servicio.

• Valor para el negocio.
1. Descripción del servicio para el usuario. • Entregables principales.
• Condiciones de la prestación.
2. Información complementaria del servicio • Prerrequisitos.
para el cliente. • Parámetros del servicio: horarios,
plazos, costes.
3. Solicitud de acceso, modificación y baja.
• Procedimiento de solicitud.
4. Preguntas frecuentes.
• Autorizaciones requeridas.
Información interna del servicio: • Componentes del servicio.

• Entornos tecnológicos.
5. Indicadores del servicio. • Instrucciones técnicas y manuales.
• Áreas internas y OLA.
6. Información técnica del servicio.
• Suministradores y UC.
7. Información del coste del servicio.
• Enlace al SLA estándar (ofertado)
8. SLA del servicio. del servicio.
• Enlaces a los SLA firmados para
9. Varios. este servicio con diversos clientes.
Figura 6.1.8. Plantilla de una ficha descriptiva de un servicio
Estados de un servicio
Requerimientos
Definido
Analizado
Aprobado
Dotado
Diseñado
Desarrollado
Construido
Probado
Desplegado
Operativo
Retirado
Fuente: Libro ITIL Diseño del Servicio publicado por OGC.
Figura 6.1.9. Secuencia de estados de un servicio en el catálogo en ITIL v3

Una vez que se define o se actualiza el catálogo, se debe generar una nueva versión
del mismo. Esta nueva versión se debe publicar en la organización TI, distribuida a
los gestores de las relaciones con el negocio y clientes para publicitar y dar a cono-
cer todos los servicios disponibles, poniéndolo accesible a los usuarios (vía web).
El catálogo de servicios requiere un mantenimiento y una actualización periódica,
incorporando los nuevos servicios o las modificaciones a los existentes. Todo cam-
bio en el catálogo debe realizarse bajo el control del proceso de gestión del cambio.
El acuerdo de nivel de servicio (SLA, Service Level

Agreement)
Los proveedores de servicio TI orientados al cliente y al servicio necesitan formali-
zar por escrito los servicios que ofrecen al cliente y los niveles de prestación de los
mismos. De esta forma, queda muy claro lo que el cliente va a recibir y los com-
promisos que asume TI, fomentándose una mayor profesionalidad y una mejora de
la confianza del negocio hacia TI.
Si bien el catálogo pone claridad en la oferta de TI, el acuerdo de nivel de servicio es el
“contrato” de prestación, y concreta los compromisos de forma específica y medible.
Como se trata en el capítulo 5 de este libro, el proceso de gestión de nivel de servi-
cio colabora con planificación e implantación de servicios en la elaboración de las
especificaciones técnicas de los servicios, que describen la solución técnica que
soporta los requisitos del cliente.
Estas especificaciones proporcionan las definiciones técnicas necesarias para pro-
veer e implantar el servicio, y sirven de partida para elaborar la primera propuesta
de acuerdo de nivel de servicio (SLA) para presentar al cliente como respuesta a su
demanda, para su revisión, negociación y acuerdo.
El SLA es pieza esencial, por ello, ISO/IEC 20000 pone un especial foco en este
punto, exigiendo expresamente que los servicios se formalicen a través de los SLA.
UNE-ISO/IEC 20000-1
Cada servicio ofrecido se debe definir, acordar y documentar en uno o más acuer-
dos de nivel de servicio (SLAs).
Se deben acordar y registrar por todas las partes relevantes los SLAs, junto con los
acuerdos de servicios de soporte, los contratos con suministradores y los correspon-
dientes procedimientos.
Los SLAs deben estar bajo el control de la gestión del cambio.
Es importante destacar que, tanto el proveedor de servicios TI como el cliente,

deben ser conscientes que se está proporcionando y recibiendo un servicio, y el
SLA es el documento que formaliza esta relación.
La Norma ISO/IEC 20000-2 pone un especial énfasis en establecer recomendacio-
nes sobre el SLA, especialmente en lo relativo a su formalización y a que debe esta-
blecerse un equilibrio entre las necesidades de los clientes y los costes.
UNE-ISO/IEC 20000-2
Acuerdos de nivel de servicio (SLAs) c) detalles sobre la autorización;
Todo servicio debería estar formalmente d) descripción breve de las comuni-

documentado en un acuerdo de nivel caciones, incluida la generación
de servicio (SLA). El SLA debería ser de informes;
autorizado formalmente por la dirección e) datos de contacto de las personas
del cliente y los representantes del pro- autorizadas a actuar ante emer-
veedor del servicio. El SLA debería estar gencias, participar en la resolu-
sujeto a la gestión del cambio, así como ción de incidentes y problemas,
el servicio que describe. así como en la recuperación del
El presupuesto y las necesidades del servicio o en la aplicación de
cliente deberían ser los elementos en soluciones temporales;
que se base el contenido, la estructura y f) horario de servicio, por ejemplo de
los objetivos del SLA. Los objetivos, res- 9:00 h a 17:00 h, y excepciones
pecto de los cuales debería medirse el al mismo (por ejemplo fines de
servicio prestado, se deberían definir semana o periodos vacacionales),
desde la perspectiva del cliente. periodos críticos para el negocio y
Los SLAs deberían incluir únicamente un cobertura fuera del horario;
conjunto adecuado de objetivos para g) interrupciones planificadas y acor-
centrar la atención en los aspectos más dadas, incluido el aviso que se
importantes del servicio. debe dar y el número por periodo;
Nota 1: Demasiados objetivos pueden gene- h) responsabilidades del cliente, por
rar confusión y conllevar un exceso de ejemplo seguridad;
gastos.
i) responsabilidades y obligaciones
El contenido mínimo que debería tener del proveedor del servicio, por
un SLA, o que se debería referenciar ejemplo seguridad;
desde él, es el siguiente:
j) directrices sobre impactos y prio-
a) descripción breve del servicio; ridades;
b) periodo de validez y/o mecanismo k) procesos de escalado y de notifi-
de control de cambios del SLA; cación;
l) procedimientos de reclamación; r) glosario de términos;

m)objetivos del servicio; s) servicios de soporte y otros rela-
cionados con el propio servicio;
n) límites de la carga de trabajo
(superior e inferior), por ejemplo la t) las excepciones a las cláusulas
capacidad del servicio de soportar incluidas en el SLA.
un número acordado de clientes
o un volumen de trabajo o la ca- Nota 2: La información volátil o común a varios
SLAs (como datos de contacto) se pueden
pacidad de procesamiento del sis- referenciar desde el SLA sin que esto
tema; suponga un impacto en la calidad de los
procesos de SLM siempre que los docu-
o) detalles de alto nivel de la gestión mentos de referencia estén también bajo el
financiera, por ejemplo códigos control del proceso de gestión del cambio.
de imputación, etc.;
Nota 3: En el SLA se suele hacer referencia al
p) acciones a llevar a cabo en caso plan de continuidad y a los detalles de la
contabilidad y del presupuesto.
de interrupción del servicio;
Nota 4: El glosario de términos normalmente suele
q) procedimientos de mantenimiento ser único y común a todos los documen-
interno; tos, incluyendo el catálogo de servicios.
El contenido del SLA debe identificar claramente a todos los intervinientes del
acuerdo de servicio: el cliente, los usuarios, las distintas áreas de la organización TI
involucradas en la prestación del servicio; así como las características del servicio a
prestar: los horarios de disponibilidad del servicio, los tiempos de respuesta, los
plazos de resolución en caso de incidente, etc.
En relación a los horarios de disponibilidad del servicio se deben definir los tramos
horarios en los que habitualmente se utiliza el servicio, por ejemplo: 7 x 24 horas,
de lunes a viernes de 8:00 a 18:00 h, etc. Además, es importante incluir directrices
para posibles ampliaciones del mismo, que contemplen el tiempo de preaviso nece-
sario (por ejemplo, esta solicitud se debe realizar al servicio de asistencia técnica
antes de las 12 AM para una ampliación del servicio por la tarde, antes de las 12 del
jueves para una ampliación el fin de semana). También se incluyen horarios espe-
ciales como en períodos de vacaciones, etc., y un calendario anual del servicio en el
caso de variaciones de las condiciones del servicio, como en campañas de Navidad,
en verano, etc.
La disponibilidad del servicio es uno de los parámetros que más impacta en el nego-
cio y uno de los más famosos en el SLA. Se definen los objetivos de disponibilidad
de los servicios dentro del horario acordado, normalmente expresados en términos de
porcentajes (99%, 99,8%, 99,99%, etc.); se incluye también el período y el método
de medida.
Sin embargo, resulta difícil relacionar los porcentajes de disponibilidad de los

servicios con las actividades de negocio. En situaciones de excelencia, se intenta
reemplazar la medida de indisponibilidad por la incapacidad del cliente para lle-
var a cabo sus actividades, por ejemplo: “el volumen de ventas que resultan afec-
tadas, como consecuencia de un fallo de TI en la provisión de un servicio de
soporte a los puntos de venta”.
Como parte de la disponibilidad, en ocasiones se pacta también la fiabilidad de los
servicios. Este elemento se expresa habitualmente mediante el número de interrup-
ciones del servicio, para ello, se utilizan indicadores como el tiempo medio entre
fallos (MTBF, Mean Time Between Failures), o el tiempo medio entre incidencias
del sistema (MTBSI, Mean Time Between System Incidents).
ITIL v3 en el libro Transición del Servicio recomienda que el SLA se cierre definiti-
vamente después de una fase piloto o al principio de la vida del servicio (early life
support), antes de que la transición se haya terminado.
El acuerdo de nivel de servicio describe en terminología del negocio “qué” se
entrega al cliente. Para complementar este documento se crea el plan de proyecto
del servicio, que detalla “cómo” TI va a entregar este servicio al cliente.
Este documento es muy importante ya que contiene toda la información adminis-
trativa necesaria para gestionar a la organización de TI en la consecución de los
objetivos comprometidos con el cliente para la prestación del servicio.
Las condiciones de asistencia y soporte para resolver incidencias, consultas o peti-
ciones, también se deben incluir en el SLA. Habitualmente se incorporan:
• Horario de asistencia.
• Provisiones para posibles ampliaciones de la asistencia, que incluyan el
tiempo de preaviso necesario.
• Horarios especiales (por ejemplo, días de fiesta, vacaciones, etc.).
• Plazo objetivo de atención a las incidencias, bien presencialmente o por otros
medios (por ejemplo, por teléfono, e-mail, etc.).
• Plazo objetivo para resolver las incidencias. Los objetivos variarán depen-
diendo de la prioridad de las incidencias.
El tiempo de respuesta del servicio, tratado en ITIL bajo el proceso de disponi-

bilidad, es otro de los factores importantes que hay que considerar. En el caso de
los servicios online, es el principal indicador utilizado para medir las transacciones.
Se deben establecer los tiempos objetivo de respuesta, medios o máximos, medidos
desde los puestos de trabajo. El tiempo de respuesta se expresa en porcentaje, por
ejemplo, el 95% de las transacciones en menos de 2 segundos.
En el caso del procesado por lotes, se establece la ventana de tiempo para la ejecu-
ción de trabajos batch (normalmente en horario nocturno), se acuerda el porcen-
taje de finalización correcta de los trabajos, el lugar para obtener y entregar los
resultados, los interlocutores por ambas partes, etc.
También se debe contemplar las condiciones relativas a la capacidad soportada por
el servicio, como son los límites de la carga de trabajo, el número de usuarios, capa-
cidad de procesamiento del sistema, los volúmenes de tráfico de comunicaciones,
el número pico de transacciones que será necesario procesar y el número máximo
de usuarios en concurrencia. Esto es importante para poder identificar las deficien-
cias en el rendimiento o el incremento de costes debido a la necesidad de ampliar la
capacidad del servicio o del número de licencias de software.
En relación a los cambios al SLA, es importante identificar los criterios para reali-
zarlos y los interlocutores necesarios para aprobar, gestionar e implementar las peti-
ciones de cambio (RFC) relacionadas con el servicio. Normalmente los criterios se
basan en la categorización y urgencia, o impacto del cambio.
Los aspectos de la continuidad ante desastres y seguridad del servicio también son
temas para analizar e incorporar al SLA:
• Se debe contemplar si el servicio está sujeto a planes para la continuidad de
los servicios TI, describiendo brevemente las condiciones que marcan la acti-
vación del plan y cómo ponerlo en marcha.
• Detalles de los objetivos de servicio reducidos o modificados en caso de
desastre (si no existe un SLA específico para tales situaciones).
• Información relacionada con la seguridad, especialmente aquellos aspectos
que sean responsabilidad del cliente (por ejemplo, copias de seguridad, cam-
bios de contraseña, etc.).
En el acuerdo de servicio es importante recoger los detalles sobre los costes, perío-
dos y fórmulas de facturación (si se factura).
Se deben detallar los contenidos, frecuencia y distribución de los informes, así
como, la frecuencia de las reuniones para la revisión del servicio.
En la figura 6.1.10 se muestran los conceptos que se deben incluir en un SLA, ali-
neados con las recomendaciones de la Norma ISO/IEC 20000-2.
El acuerdo de nivel de servicio es el contrato que TI firma con sus clientes, en torno
a este acuerdo todas las áreas y procesos de la organización deben enfocar su activi-
dad para velar por su cumplimiento.
Contenido de un SLA • Asistencia:

– Horario de asistencia (cuando no sea
el mismo que el horario de servicio).
• Título y breve descripción del
servicio. – Horarios especiales.
• Objetivos del servicio. – Tiempo objetivo de respuesta a las
incidencias.
• Las partes implicadas en el acuerdo.
– Tiempo objetivo para resolver las
• Titular del servicio. Firmantes.
incidencias.
• Fechas: comienzo, término, revisión.
• Procedimientos de escalado y de
• Ámbito del acuerdo, lo que cubre y lo
notificación.
que se excluye.
• Procedimientos de reclamación.
• Responsabilidades del proveedor del
servicio y del cliente. • Acciones a llevar a cabo en caso de
interrupción del servicio.
• Descripción de los servicios cubiertos.
• Interrupciones planificadas y
• Horario de prestación, excepciones
acordadas, incluido el aviso que se
al mismo y períodos críticos para el
debe dar y el número por período.
negocio y cobertura fuera del horario.
• Responsabilidades del cliente.
• Disponibilidad del servicio y capacidad
soportada por el mismo. • Responsabilidades y obligaciones del
proveedor del servicio.
• Procesado por lotes (batch).
• Detalles de alto nivel de la gestión
• Autorizaciones.
financiera.
• Comunicación, reuniones e informes.
• Mecanismo de control de cambios
• Datos de contacto. del SLA. Procedimientos de
• OLA y UC de soporte con el propio mantenimiento interno.
servicio. • Glosario de términos.
• Continuidad y seguridad de los • Excepciones a las cláusulas incluidas
servicios TI. en el SLA.
• Directrices sobre impactos y
prioridades.
Fuente: UNE-ISO/IEC 20000 y e.p.
Figura 6.1.10. Contenido ejemplo de un SLA
Alternativas para la estructuración del SLA

La definición del contenido de los SLA es muy importante en una organización de
provisión de servicios TI. No olvidemos que regula la relación de la prestación con-
tinua del servicio que TI proporciona a sus clientes.
Según ITIL, hay diversas formas de establecer los SLA: basado en el servicio,
basado en el cliente y multinivel.
SLA basado en el servicio. Cuando un SLA cubre un servicio y es el mismo para

todos sus clientes. Por ejemplo, se puede establecer un único SLA para el servicio de
correo electrónico de una organización que cubra a todos los clientes de ese servicio.
Aunque puede parecer bastante sencillo, sin embargo pueden surgir dificultades si
los requisitos específicos de clientes varían para un mismo servicio, o si las caracte-
rísticas de la infraestructura TI implican que sean inevitables distintos niveles
de servicio (por ejemplo, la central puede estar conectada por medio de una LAN de
alta velocidad, mientras que las oficinas locales utilizan una línea de menor veloci-
dad). En tales casos, serán necesarios distintos objetivos en un mismo acuerdo.
También pueden surgir dificultades al determinar quién debería firmar tales acuer-
dos.
SLA basado en el cliente. Soporta un acuerdo con una área cliente específica, que
cubra todos los servicios que utilizan. Por ejemplo, se puede llegar a acuerdos con
el departamento de finanzas de una organización para cubrir, por ejemplo, el sis-
tema financiero, el de contabilidad, el de nóminas, la facturación y otros servicios
que utilicen.
A menudo, los clientes prefieren este acuerdo, ya que cubren todos sus requisitos
con un solo documento. Sólo se requiere una firma, lo que simplifica su gestión y
evolución posterior.
SLA multinivel. Algunas organizaciones, principalmente multinacionales, han

decidido adoptar una estructura de acuerdos de nivel de servicio de nivel múltiple.
Por ejemplo, una estructura de tres niveles como la siguiente:
1. Nivel corporativo. Cubre todos los aspectos genéricos sobre la prestación
de servicios para los clientes en toda la organización. Generalmente estos
aspectos son menos volátiles, por lo que será necesario realizar menos actua-
lizaciones.
2. Nivel del cliente. Cubre todos los aspectos sobre la prestación de servicios
que resultan relevantes para un grupo de clientes particular, sin que importe
el servicio utilizado.
3. Nivel del servicio. Cubre todos los aspectos sobre la prestación de servicios
aplicado a un servicio concreto y a este grupo de clientes específico (para
cada servicio recogido en los SLA). En la figura 6.1.11 se muestra una
estructura de este tipo.
Nivel corporativo
Nivel del cliente
Nivel del servicio
Fuente: Libro ITIL Provisión de Servicio publicado por OGC.
Figura 6.1.11. Acuerdos de nivel de servicio multinivel
Buenas prácticas relativas al proceso y al SLA

Realmente el proceso de gestión de nivel de servicio se puede llevar a cabo de múl-
tiples formas, ya que no hay una secuencia de actividades precisa que conforme
flujo o un conjunto de pasos que se deben seguir. Pero si hay un conjunto de bue-
nas prácticas que conviene tener en consideración para tener éxito, en este apartado
se detallan algunas consideraciones al respecto.
UNE-ISO/IEC 20000-2
El proceso de gestión de nivel de

suspensión temporal. El proceso de ges-
servicio
tión de nivel de servicio (SLM) debería ser
Los cambios importantes en el negocio, flexible para adecuarse a estos cambios.
debidos, por ejemplo, al crecimiento, El proceso de SLM debería asegurar que
fusiones y reorganizaciones del negocio, el proveedor del servicio continua focali-
y los cambios en los requisitos del cliente, zado en el cliente durante la planifica-
pueden implicar el ajuste de los niveles ción, implantación y la gestión continua
de servicio, su redefinición o incluso su del servicio prestado.
Se le debería dar al proveedor del servi- e) entrada al programa de mejora

cio la información adecuada para per- del servicio.
mitirle que comprenda las motivaciones
y requisitos del negocio del cliente. El proceso debería animar tanto al pro-
veedor del servicio como al cliente a
El proceso de SLM debería gestionar y
desarrollar una actitud proactiva con
coordinar a quienes contribuyen al nivel
de servicio, para incluir: objeto de garantizar que ambos tienen
una responsabilidad compartida sobre
a) acuerdo en los requisitos del ser- el servicio.
vicio y en las características de la
carga de trabajo esperada del La satisfacción del cliente es una parte
servicio; importante de la gestión de nivel de
servicio pero debería reconocerse que
b) acuerdo en los objetivos de servicio;
es una medida subjetiva, mientras que
c) medición e informe de los niveles los objetivos de servicio incluidos en el
de servicio conseguidos, cargas de SLA deberían ser medidas objetivas. El
trabajo y explicaciones cuando proceso de SLM debería trabajar con-
no se alcanzan los objetivos acor- juntamente con los procesos de gestión
dados; de relaciones con el negocio y gestión de
d) inicio de la acción correctiva; suministradores.
En relación a la gestión del SLA los principales temas a tener en cuenta son:
Involucrar al cliente. Siempre que sea posible es necesario involucrar al cliente

desde el comienzo de la actividad. En la relación con el cliente es conveniente crear
un borrador con las líneas maestras del SLA que sirva como punto de partida, para
posteriormente ir ampliando y profundizando en sus contenidos. Es fundamental
que el cliente participe y sienta el SLA como suyo. Si TI profundiza demasiado en
su definición hasta el punto de presentar el SLA como un “hecho consumado”
puede provocar el rechazo en el cliente.
En muchas organizaciones se utilizan documentos proforma, creados a partir de
definiciones de SLA pilotos, como punto de partida para todos los acuerdos
de nivel de servicio.
Redacción de los acuerdos. La redacción de los SLA deberá ser clara y concisa,
sin dejar lugar a la ambigüedad. Generalmente no es necesario que los acuerdos
estén redactados utilizando una terminología legal; en realidad la utilización de
un lenguaje claro ayudará a una mejor comprensión. Como comprobación resulta
muy útil que una persona independiente, que no esté implicada en la redacción
del documento, realice una lectura final del mismo. Esta revisión suele poner de
manifiesto las posibles ambigüedades y dificultades, lo que nos permite tomas las
medidas oportunas de revisión y aclaración.
También merece la pena recordar que los acuerdos de nivel de servicio pueden dar
cobertura a los servicios ofrecidos a diferentes comunidades lingüísticas, por lo que
es necesario contemplar la disponibilidad de los SLA en los diferentes idiomas. En
este aspecto hay que dedicar un especial cuidado a la terminología, ya que un SLA
puede revisarse en diferentes países y, por tanto, puede ser necesario considerar los
aspectos de terminología, estilos y diferencias culturales.
Negociación y acuerdo. Una vez definido y redactado un documento base del

acuerdo, se deben mantener negociaciones con el cliente, o con sus representantes,
para concretar los contenidos del SLA y los objetivos finales del nivel de servicio.
En este proceso también es necesario establecer reuniones previas con las áreas
internas de TI y con los proveedores para asegurarse de que estos niveles son alcan-
zables y cerrar los acuerdos de nivel operativo (OLA) y los contratos de soporte
(UC) correspondientes.
Para realizar esta labor, el gestor del nivel de servicio deberá realizar su propio pro-
grama de reuniones y negociaciones con los clientes (a través de relaciones con el
negocio) para asegurar que se identifican los requisitos reales, y con las áreas inter-
nas y los suministradores (a través de gestión de suministradores) para garantizar
que se cubren adecuadamente los compromisos establecidos en el SLA.
En este punto es importante formalizar con el cliente los mecanismos de revisión y
notificación, los intervalos y los formatos de los informes de los SLA.
La frecuencia y el formato de las reuniones de revisión del servicio también deben
acordarse con los clientes. Es muy recomendable utilizar intervalos regulares, y en
cuanto a los informes periódicos, al menos se deberían alinear con los ciclos de las
revisiones. Es conveniente la realización de reuniones presenciales para facilitar la
comunicación personal, pero en el caso de dispersión geográfica será recomendable
la utilización de otros formatos de reunión.
Firma del acuerdo. Este aspecto es esencial para que el SLA acordado tenga la
suficiente credibilidad por las dos partes, por lo que hay que garantizar que al tér-
mino del proceso de redacción y negociación, el acuerdo de nivel de servicio sea
firmado por los cargos apropiados, tanto del lado del cliente como del proveedor
de TI.
Esto garantizará el compromiso de que ambas partes intentarán hacer todo lo que
sea posible para cumplir los SLA firmados. De forma general, cuanto más alta sea
la jerarquía de los firmantes, mayor será esta garantía.
Una vez firmado y cerrado el acuerdo de nivel de servicio se debe formalizar den-
tro de la organización TI como un activo más, y por tanto estará sujeto al control
de gestión del cambio, mediante la correspondiente formalización de una petición
de cambio. A partir de este punto, cualquier modificación estará sujeta a la gestión
y aprobación del proceso de gestión del cambio.
Difusión de los SLA. Una vez cerrado el SLA, es fundamental utilizar una buena
promoción y difusión que permita asegurar que los clientes y las diferentes áreas del
proveedor de servicios TI están enterados de su existencia y de los objetivos clave.
En este punto es clave que el centro de servicio al usuario tenga conocimiento de
los contenidos de los SLA, ya que es el primer punto de contacto de los incidentes,
consultas y quejas de los clientes. Si el personal del centro de servicio al usuario no
está bien informado de los SLA en vigor y no actúa en consecuencia, los clientes
perderán rápidamente su confianza en estos acuerdos.
Mantenimiento de los SLA. El SLA es un elemento de información más dentro

de la organización de TI y, una vez operativo, está sujeto al mismo control y admi-
nistración que el resto de los elementos de configuración (CI, Configuration Item).
Por tanto, cualquier propuesta de modificación está sujeta al control y aprobación
del proceso de gestión del cambio.
Revisión de los SLA. Los acuerdos del nivel de servicio deben revisarse periódica-
mente con los clientes para garantizar si aún son validos y adecuados a las necesida-
des del negocio y las capacidades de la organización TI, por ejemplo, anualmente
en línea con el ciclo financiero.
UNE-ISO/IEC 20000-1
Los SLAs se deben revisar periódicamente por las partes, para asegurar que se
encuentran actualizados y continúan siendo eficaces con el transcurso del tiempo.
Para cubrir este objetivo es necesario mantener reuniones periódicas de revisión

con los clientes (o sus representantes) para examinar los logros del servicio en el
último periodo y para prever cualquier aspecto del siguiente periodo. Suele ser fre-
cuente mantener estas reuniones con una periodicidad mensual o, como mínimo,
trimestral.
Del resultado de estas reuniones, y si es necesario, se debe emplazar al cliente y al
proveedor a llevar a cabo acciones apropiadas para mejorar áreas en las que no se
estén consiguiendo los objetivos. Todas las medidas acordadas se deberían registrar
en las actas, y se debería revisar el progreso y los resultados obtenidos en la
siguiente reunión.
Acuerdos de servicio de soporte (OLA y UC)

El proceso de gestión de nivel de servicio establece una cadena de acuerdos que le
permita asegurar que los compromisos establecidos en el SLA son alcanzables
y que, en el caso que se produzca cualquier impacto negativo o rotura de SLA,
le facilitará la localización del punto de fallo y su resolución. Así, para garantizar la
cobertura de los SLA este proceso establece acuerdos que implican a la organiza-
ción interna del proveedor de TI y a los suministradores externos que le proporcio-
nan bienes o servicios.
Con las unidades internas se formalizan acuerdos de nivel operativo (OLA, Opera-
tional Level Agreement) en los que se recogen todos los compromisos necesarios de
cada una de las áreas intervinientes relacionadas con su aportación al cumplimiento
del SLA.
Para los suministradores externos establecen los contratos de soporte (UC, Under-
pinning Contract) en los que se recogen los compromisos de los suministradores en
el cumplimiento de los SLA que soportan. El contrato de soporte con terceros se
gestiona entre dos procesos: la gestión de nivel de servicio establece los requisitos
de servicio que se deben exigir al suministrador, mientras que la gestión de sumi-
nistradores se encarga de la negociación y su firma.
ISO/IEC 20000-2 establece la base para el desarrollo de esta cadena de acuerdos.
UNE-ISO/IEC 20000-2
Los servicios de soporte de los cuales trador de servicios. Esto incluye los grupos
depende el servicio prestado se deberían internos que proveen parte del servicio
documentar y acordar con cada suminis- ofrecido por el proveedor del servicio.
Es habitual que las organizaciones tengan contratos con suministradores para la

prestación de los servicios. Pero habitualmente, estos contratos no están alineados
completamente con lo comprometido en los SLA. Se debe trasladar a estos contra-
tos los principales requerimientos que el suministrador debe cumplir para que la
organización de TI pueda garantizar los niveles de servicio comprometidos.
En el caso de los OLA, el cambio que se produce en la organización de TI es

mucho más drástico. La firma de acuerdos internos requiere la estructuración de
TI en unidades o grupos de soporte, y que cada grupo de soporte tenga claramente
definidas sus fronteras de actuación. Estos grupos de soporte deben transformar su
mentalidad y ser conscientes de que están prestando un servicio interno (por ejem-
plo, almacenamiento, bases de datos, frontales web, comunicaciones, etc.). Desde
este momento, la comunicación entre las unidades estará basada en “tickets” de tra-
bajo, provenientes de incidentes, peticiones o de partes de trabajos mayores. La
implantación de los OLA en el proveedor de TI supone una fuerte transformación
cultural y organizativa.
Por ello, no es frecuente encontrar una organización que se relacione internamente
basándose en compromisos internos de nivel de servicio (OLA).
En su mayoría, los contratos de soporte dan servicio directamente a los grupos
internos y son éstos los que soportan el servicio final. Por tanto, suelen ser los gru-
pos internos de especialistas los que tratan a nivel técnico con el soporte de los
suministradores. Excepto en el caso de externalización completa de un servicio (por
ejemplo, el correo electrónico), en el que el suministrador es controlado directa-
mente por los gestores del servicio.
Lo habitual es que un OLA y un UC den soporte a múltiples servicios, por ejem-
plo el equipo de técnica de sistemas interno y el soporte de los diferentes fabrican-
tes de servidores midrange darán soporte a todos los SLA de los servicios.
En la figura 6.1.12 se muestra un ejemplo de una cadena de aseguramiento de los
SLA para un departamento de administración en base a una cascada de OLA y UC.
Como se puede observar en la figura 6.1.12, si esta cadena se realiza con rigor y
compromiso, el nivel de riesgo de incumplimiento de los acuerdos con los clientes
es bajo. Si a esto le añadimos la monitorización y seguimiento de los acuerdos, con
el objetivo de identificar y proponer acciones de mejora, nos encontramos con una
herramienta muy poderosa, que nos posibilita la mejora de la satisfacción de los
clientes y, desde el punto de vista interno, nos permite optimizar y mejorar la efi-
ciencia en la prestación de los servicios TI.
Los SLA, OLA y UC se deben mantener actualizados, y es necesario revisar periódi-
camente, y por lo menos una vez al año, que aún tienen la cobertura adecuada, están
actualizados y continúan alineados con las necesidades y estrategia del negocio.
Estas revisiones deberían garantizar que tanto los servicios cubiertos como los obje-
tivos de cada uno son todavía relevantes y que no se ha realizado ningún cambio sig-
nificativo que invalide el acuerdo de algún modo, como por ejemplo cambios en la
infraestructura TI, el negocio, el proveedor, etc.
Figura 6.1.12. Ejemplo de la cadena de aseguramiento de los SLA

para un departamento de administración de la empresa
En el caso que se detecte un cambio se deberían actualizar los acuerdos, bajo el

control de gestión del cambio y de las unidades internas involucradas para que
reflejen la nueva situación.
A modo de ejemplo, en la figura 6.1.13 se muestra la información recogida habi-
tualmente en un acuerdo de nivel operativo.
El contrato de soporte es un documento contractual entre la organización de TI y
un suministrador externo, por tanto utiliza el formato de contrato habitual de la
empresa o del suministrador. El UC debería tratar los conceptos enunciados en
la figura 6.1.14.
Un contrato de soporte (UC) es el documento contractual entre la organización TI
y un suministrador de servicios externo. Este contrato define el objetivo, alcance y
características del servicio que se va a prestar.
Estructura de un acuerdo de
nivel operativo (OLA)
Introducción:
• SLA de referencia.
• Unidad TI que lo soporta.
Requerimientos:
• Acuerdos del servicio.
• Descripción del nivel de servicio (SLA).
• Plan de proyecto del servicio interno.
• Objetivo y alcance del servicio.
• Ámbito de aplicación.
• Funcionalidades proporcionadas.
Características del servicio interno:

• Niveles internos de servicio y niveles SLA de
referencia.
• Horario de servicio y soporte, disponibilidad y
fiabilidad, continuidad y seguridad, rendimiento.
• Otros OLA y UC que utiliza.
• Explotación y operación, técnicas, etc.
Responsables involucrados:
• Responsable de planificación e implantación de
servicios nuevos o modificados.
• Responsable de gestión de nivel de servicio.
• Responsables de procesos/departamentos
afectados.
• Responsables de otros procesos/departamentos
involucrados.
Figura 6.1.13. Contenido tipo de un acuerdo de nivel operativo (OLA)

Contenidos de un contrato de soporte (UC)
Introducción:
• SLA y OLA de referencia.
• Nombre del suministrador. Unidad TI que lo soporta.
Requerimientos:
• Acuerdos de nivel de servicio (SLA) y
operativos (OLA).
• Plan de proyecto del servicio.
Descripción del servicio:

• Objetivo y alcance del servicio.
• Ámbito de aplicación y relaciones con otros servicios.
• Funcionalidades proporcionadas.
Características del servicio interno:

• Funcionales.
• Horario de servicio y soporte, disponibilidad y
fiabilidad.
• Niveles internos de servicio. Continuidad y seguridad,
rendimiento.
• Interfaces.
• Explotación y operación, etc.
Condiciones comerciales:
• Coste del servicio y forma de pago.
Mecanismos de control y seguimiento:

• Indicadores y métricas, informes de gestión.
Responsables involucrados:
• Responsable de planificación e implantación de
servicios nuevos o modificados.
• Responsable de nivel de servicio.
• Proveedores de servicios externos.
Figura 6.1.14. Contenido tipo de los contratos de soporte (UC)

Supervisión y monitorización del servicio y de los SLA

Una vez activado el servicio, con su SLA correspondiente, se inicia su explotación.
Desde este momento se debe poner en marcha la actividad de supervisión del servi-
cio y de monitorización de los niveles alcanzados, para determinar su calidad, fiabi-
lidad y disponibilidad. Se generan los informes sobre el nivel de servicio para anali-
zar y demostrar su cumplimiento.
UNE-ISO/IEC 20000-1
Los niveles de servicio se deben monitorizar y se deben generar informes de dichos

niveles con relación a los objetivos, mostrando tanto la información actual como las
tendencias. Las razones para las no conformidades se deben comunicar y revisar.
Durante la actividad de redacción y negociación del acuerdo es cuando se anali-

zan y determinan las métricas para medir el servicio, y es justo en este punto en
el que hay que comprobar que existen los medios necesarios para poder monito-
rizar su cumplimiento. No se debería incluir ninguna métrica en un SLA a menos
que pueda medirse y monitorizarse de una manera efectiva y según acuerdo
mutuo. Esto es importante, ya que incluir elementos que no puedan monitori-
zarse de forma eficaz provocará conflictos y la eventual pérdida de confianza en
los SLA.
En la actividad de monitorización se debe prestar una atención especial a cada
incumplimiento (denominado ruptura o violación) de los niveles de servicio acor-
dados, con el fin de determinar qué fue exactamente lo que causó la pérdida del
servicio y qué se puede hacer para evitar que vuelva a ocurrir. Si se determina que
el nivel de servicio es ahora inalcanzable, es aconsejable revisar y volver a acordar
unos objetivos diferentes. Si la ruptura del servicio ha sido causada por un fallo de
una tercera parte o de un grupo de soporte interno, puede que también sea necesa-
rio revisar el contrato de soporte o el OLA correspondiente.
En los informes se deberá realizar la comparación entre los valores de los indicado-
res obtenidos y los valores objetivo o umbrales de referencia.
Los informes generados y la información que contienen tienen como objetivo la
comprobación del cumplimiento de los SLA y el análisis de su evolución, para
detectar posibles acciones de mejora a los SLA y los componentes de la propia
organización TI. Es decir, estos informes están destinados tanto a la gestión de
nivel de servicio como a la propia gestión interna, por tanto, el contenido y natura-
leza de estos informes deberá ajustarse a cada destinatario.
Para realizar los informes el proceso de generación de informes de servicio necesita

la definición y recopilación de toda la información necesaria en forma de indicado-
res y métricas. Estos indicadores y métricas son acordados y suministrados por
otros procesos de gestión del servicio, tales como gestión de la disponibilidad, ges-
tión del incidente, etc.
La naturaleza de estos indicadores estará relacionada con información de disponi-
bilidad y fiabilidad del servicio. También es muy interesante disponer de informa-
ción relacionada con la opinión del cliente respecto a la calidad percibida en la pres-
tación del servicio.
Para poder realizar esta actividad de monitorización de SLA y emisión de informes
es necesario tener el soporte de las herramientas que permita realizar la captura y
análisis de los indicadores y métricas de calidad del servicio, así como la evaluación
del grado de cumplimiento de los acuerdos del nivel de servicio establecidos con
los clientes.
Las características básicas que deben reunir las herramientas que constituyan el sis-
tema de monitorización de los servicios son las siguientes:
• Facilidad de interconexión con sistemas y herramientas de monitorización
de los sistemas, así como herramientas de gestión con otros procesos con el
fin de recopilar las métricas e indicadores establecidos.
• Posibilidad de definición y parametrización de indicadores y métricas.
• Posibilidad de definición y parametrización de valores umbrales de las métricas.
• Generación de alarmas de incumplimiento de los acuerdos de nivel de servi-
cio activos y alarmas de proximidad al incumplimiento.
• Generación online de informes del nivel de servicio.
Mejora de los servicios y programa de mejora del

servicio (SIP, Service Improvement Program)
Como consecuencia de la actividad de supervisión y monitorización de los servi-
cios, de las reuniones con el cliente (relaciones con el negocio), etc., se identifica
un conjunto de posibles mejoras que se pueden realizar. Las mejoras se recogen en
un documento denominado programa de mejora del servicio (SIP). Como todo
plan de proyecto, establece los objetivos y alcance de las mejoras, la descripción de
las actividades que se deben realizar, las responsabilidades de las distintas áreas par-
ticipantes, la planificación de las actividades, así como, los mecanismos para su con-
trol y seguimiento. Este programa, por tanto, establece el objetivo y alcance de las
mejoras, su justificación en términos de coste/beneficio, las fases, actividades, pla-

nificación y responsabilidades, así como las métricas necesarias para el seguimiento
del proyecto y validación de las mejoras.
UNE-ISO/IEC 20000-1
Las acciones de mejora definidas durante este proceso se deben registrar y constitu-
yen una entrada al plan de mejora del servicio.
En el momento que se identifique una dificultad subyacente que esté impactando

negativamente sobre la calidad del servicio, gestión de nivel de servicio debe, en cola-
boración con el resto de procesos (especialmente con la gestión del problema y la ges-
tión de la disponibilidad), promover un programa de mejora del servicio (SIP).
Las iniciativas incluidas en los SIP también pueden centrarse en aspectos como la
formación de los usuarios, la documentación y las pruebas de los sistemas. Cuando
para la mejora de un servicio sea necesario modificar un proceso, la actividad se
coordinará con el responsable del propio proceso para que la implemente.
Todo SIP debe ser aprobado por la gestión del cambio antes del inicio de su ejecu-
ción.
Los SIP generados, que están destinados a la mejora de los servicios, se incorpora-
rán en el “Plan de mejora unificado de los procesos y de los servicios” (véase el
capítulo 4), con el fin de coordinar desde un único punto todas las acciones de
mejora en TI, de los servicios y de los procesos.
El contenido habitual de un SIP se muestra en la figura 6.1.15.
Una buena práctica a tener en cuenta es la dotación de un presupuesto anual para
financiar las mejoras (plan de mejora unificado de los procesos y los programas de
mejora de los servicios). De esta forma, las acciones se pueden llevar a cabo más
rápidamente. Esta práctica es muy útil, ya que hace que tanto la gestión de nivel de
servicio como la mejora de los procesos sea cada vez más proactiva y previsora.
Mejora del proceso de gestión de nivel de servicio

Al igual que en el resto de los procesos, el responsable de gestión de nivel de servi-
cio, también debe velar por la mejora continua de su propio proceso. Las acciones
identificadas se incluirán y coordinarán con el “Plan de mejora unificado de los pro-
cesos y de los servicios” descrito en el capítulo 4.
Programa de mejora del Descripción modificaciones OLA y UC

servicio (SIP)
Detalles acciones de mejora
propuestas Clientes actuales: para
cada área/proceso:
Introducción
• Gestión del incidente.
Objetivo y alcance.
• Gestión de la seguridad.
Clientes actuales: • Gestión de la disponibilidad.
• Cliente. • Gestión de la capacidad.
• SLA referencia.
• Fecha de inicio. Plan de proyecto para la mejora
• Servicio. Descripción de la mejora
Plan de trabajo. Actividades y
Áreas de mejora
responsables.
Descripción de las debilidades y
Planificación de actividades. Fases,
áreas de servicio.
actividades, hitos.
Acciones de mejora Impacto.
Descripción a alto nivel de las Estimación de esfuerzo.

acciones de mejora del servicio. Estimación de costes.
Justificación coste/beneficio. Cambios asociados:
• Descripción.
Áreas TI involucradas • Justificación.
Área. • Beneficios esperados.
Justificación.
Participación.
Fuente: Libro ITIL Provisión de Servicio publicado por OGC y Telefónica.
Figura 6.1.15. Contenido tipo de un SIP

Relaciones con otros procesos y áreas

Dado que este proceso tiene una interrelación amplia con los otros procesos es
necesario revisar las relaciones con el resto de ellos y con otras áreas de TI. En la
figura 6.1.16 se presentan las principales relaciones de gestión de nivel de servicio
en el ciclo de creación y modificación de servicios.
Seguidamente se incluye una breve descripción de la relación de cada uno de los pro-
cesos reflejados en la figura 6.1.16 con el proceso de gestión de nivel de servicio.
Figura 6.1.16. Principales relaciones del proceso de gestión de nivel de servicio

con otros procesos y áreas de TI
El proceso de relaciones con el negocio, podemos decir que se encarga de mante-

ner las “relaciones públicas” para la gestión de nivel de servicio. Relaciones con el
negocio entiende más de las funcionalidades que necesita el negocio y establece
y mantiene la relación con el cliente, mientras que la gestión de nivel de servicio
tiene un conocimiento más preciso de lo que TI es capaz de aportar. El proceso de
relaciones con el negocio requiere la participación de la gestión de nivel de servicio
en todos los aspectos relacionados con la satisfacción de las necesidades del cliente
mediante servicios ya disponibles en el catálogo o mediante la confección o revi-
sión de los acuerdos del nivel de servicio. Una vez puesto en marcha el servicio, ges-
tión de nivel de servicio “rinde cuentas” al cliente sobre los niveles de servicio
alcanzados y analiza conjuntamente las opciones de mejora.
En el caso del proceso de planificación e implantación de servicios nuevos o modi-
ficados, la interrelación sigue un esquema similar: las relaciones con el negocio se
encargan de entender al cliente y el establecimiento de los requisitos, mientras que
la gestión de nivel de servicio proporciona un catálogo de servicios actualizado y la
definición del acuerdo de nivel de servicio (SLA).
El proceso de generación de informes del servicio produce los informes que nece-
sita la gestión de nivel de servicio para informar a los clientes y a TI sobre los nive-
les de servicio. Los informes deben contemplar información relevante de forma
que permita analizar aspectos clave del servicio, como su rendimiento, cargas
de trabajo, cumplimiento de los compromisos con los clientes (SLA), incidentes
graves, etc. Los informes deben servir para la gestión de los servicios y la defini-
ción de acciones correctoras y de mejora de los servicios.
El proceso de elaboración de presupuestos y contabilidad de los servicios de TI
proporciona la información económica necesaria para la toma de decisiones en
cuanto a los niveles de servicio y para que los compromisos se asuman con un
conocimiento preciso de los costes.
Con el resto de procesos, la gestión de nivel de servicio establece el valor de los
parámetros en SLA que se pueden cumplir por TI, para posteriormente realizar el
seguimiento de los mismos. Así, con la gestión de la continuidad y disponibilidad
se establecerán los umbrales de los SLA de emergencia y los valores de disponibili-
dad y de rendimiento de los servicios; con la gestión de la seguridad los temas rela-
tivos al nivel de seguridad a comprometer; con la gestión de la capacidad se defi-
nen las necesidades de proceso, almacenamiento, etc.
La relación con la gestión del cambio es de las más fundamentales, pues gestión de
nivel de servicio (como todos los otros procesos) no puede cambiar nada que no
esté validado por la gestión del cambio. Por ello, se deben generar peticiones de
cambio antes de crear un nuevo SLA o de modificar uno existente, así como para
ejecutar las modificaciones derivadas de los planes de mejora del servicio.
En relación con el área de desarrollo de aplicaciones, el proceso de planificación y
diseño de infraestructuras y el de operación del servicio, se tratan los requisitos a
cumplir por cada una para la satisfacción de los niveles de servicio. Los compromisos
con cada una de estas partes se formalizarán en un acuerdo de nivel operativo (OLA).
El proceso de gestión de suministradores recibe los requisitos a cumplir, para que

los contratos de soporte (UC) permitan a TI cumplir con los SLA.
La relación con todos los procesos y funciones de TI anteriormente descritos per-
mitirá al proceso de gestión de nivel de servicio desarrollar su labor de definir y
acordar los SLA necesarios para dar cobertura a las demandas del negocio. Esta
relación también es clave en la faceta proactiva de este proceso, para analizar y esta-
blecer planes de mejora de los servicios.

Para poder gestionar el proceso y sus objetivos, es necesario establecer las medidas
que permitirán evaluar el funcionamiento y los resultados del proceso de gestión
de nivel de servicio.
La medición del proceso será necesaria para su control, redundando en una gestión
más adecuada.
Mediante el control del proceso se podrá evaluar su funcionamiento y se estará en
disposición de tomar acciones correctivas y proactivas de mejora, al objeto de
hacerlo más eficiente, eficaz y adaptable (optimización).
Para llevar a cabo el control del proceso se establecerán indicadores que ayuden a
medir objetivamente el funcionamiento y la evolución del proceso. A continuación
se incluye una selección de indicadores que facilitan esta labor:
• Número o porcentaje de los servicios cubiertos con SLA, útil en etapas de
transformación.
• Número o porcentaje de SLA sin contratos de soporte UC y sin acuerdos
de nivel operativo OLA, que los respalden.
• Número o porcentaje de SLA monitorizados y de los cuales se emiten infor-
mes periódicos.
• Número o porcentaje de acuerdos de nivel de servicio revisados en los plazos
planificados y con su correspondiente documentación actualizada.
• Número o porcentaje de SLA, OLA o UC que están fuera de su fecha de
cobertura.
• Número y gravedad de las interrupciones de servicio.
• Porcentaje de las interrupciones de servicio tratadas y analizadas.
• Porcentaje de cumplimiento de los acuerdos de nivel de servicio y su evolu-

ción durante un periodo.
• Tendencia de la reducción de roturas de SLA causadas por contratos de
soporte UC (mejorando o renegociando contratos).
• Tendencia de la reducción de roturas de SLA causadas por acuerdos de nivel
operativo OLA.
En el gráfico de la figura 6.1.17 se muestra un resumen de los indicadores más rele-

vantes para este proceso seleccionados por un grupo de trabajo de itSMF España.
Métricas principales del proceso
Fuente: itSMF España.
Figura 6.1.17. Métricas para este proceso del Modelo Abreviado de Métricas
de itSMF España
Roles participantes en la gestión del proceso

Como en el resto de los procesos, los roles intervinientes en la gestión de nivel de
servicio se estructuran en los roles propios del proceso y los roles ajenos al proceso
(el gestor del nivel de servicio).
• Responsable del proceso de gestión de nivel de servicio. Es el responsable
último del funcionamiento del proceso y de los cumplimientos de los niveles
de servicio. Coordina a todos los gestores de nivel de servicio. Reporta al res-
ponsable de la gestión del servicio.
• Gestores de nivel de servicio. Son los responsables de la creación y gestión
de los acuerdos de nivel de servicio, coordinan a las distintas áreas y procesos
de la organización de TI para asegurar la disponibilidad y calidad de los SLA
firmados con los clientes. Asimismo, es el responsable de que el catálogo de
servicios esté en todo momento actualizado y disponible.
• Administrador y soporte del proceso de gestión de nivel de servicio. Es res-
ponsable de la administración técnica (sistemas y herramientas) del proceso.
Se ocupa de proporcionar y mantener los medios técnicos necesarios para
una gestión eficiente del proceso ayudando al gestor del nivel de servicio en
el control de toda la actividad.
• Administrador del catálogo de servicios. Es el responsable del manteni-
miento del catálogo asegurando la definición, mantenimiento, publicación y
divulgación de los servicios.
Los roles ajenos que son relevantes en este proceso son:

• Los gestores del resto de procesos que se interrelacionan con la gestión de
nivel de servicio para acordar los niveles de servicio a comprometer en la pre-
paración el SLA y, una vez operativo el servicio, para velar por su cumpli-
miento.
(process owner), define el proceso y se encarga de la mejora continua del
mismo. Todo ello, de una forma integrada con el modelo de gestión de TI
incorporado en el SGSTI.
En la figura 6.1.18 se muestra un esquema con los roles para este proceso.
Roles del proceso
Responsable de la
Responsable del
proceso SLM
Gestores del
nivel de servicio
Gestores de otros
procesos y áreas TI
SGSTI
Administrador
catálogo de servicios Administrador y
soporte del proceso
Propietario del
modelo (SGSTI)
Figura 6.1.18. Roles para el proceso de gestión de nivel de servicio
Resumen
El proceso de gestión de nivel de servicio es clave para cumplir con las expectativas
de los clientes de TI, manteniendo y mejorando la estabilidad de los servicios ya
que regula y controla toda la cadena de aseguramiento de los acuerdos de nivel de
servicio firmados con los clientes.
El proceso mantiene la calidad y fiabilidad de los servicios, velando, tanto por la
creación de SLA fiables y acordes con las necesidades del negocio, como por el con-
trol y mejora reactiva/proactiva que permiten mejorar la calidad de la prestación de
los servicios de TI. Este proceso trabaja en estrecha colaboración con los procesos
y con las áreas técnicas.
Los principales elementos que componen el proceso son: el responsable del pro-
ceso, el catálogo de servicios, los SLA, los OLA, los UC y los programas de mejora
del servicio (SIP).
Beneficios
La mejora en la calidad y la reducción de las interrupciones del servicio, que aporta
una efectiva gestión de nivel de servicio, permite la obtención de ahorros económi-
cos significativos. Por un lado, el cliente puede realizar sus funciones de negocio de
forma predecible y minimizar el impacto negativo en sus actividades mediante el
cumplimiento de los acuerdos de servicio establecidos y la planificación de paradas
de mantenimiento del servicio, y por otro, la organización TI gastará mucho menos
tiempo y esfuerzo al tener menos incumplimientos de SLA que resolver.
Entre los beneficios de la gestión de nivel de servicio se pueden destacar:
• La prestación del servicio TI se diseña para satisfacer los requisitos del servi-
cio de los clientes.
• Permite mejorar las relaciones con los clientes.
• Las dos partes firmantes del SLA tienen una visión clara de sus funciones y
responsabilidades, evitando posibles omisiones o malentendidos.
• Se tienen objetivos específicos y acordados, con los que se puede comparar y
medir la calidad del servicio; “si no aspira a nada, probablemente eso sea lo
que consiga”.
• Permite centrar el esfuerzo en TI en los servicios clave para el negocio.
• La monitorización de los servicios facilita la identificación de áreas de debili-
dad, permitiendo emprender las acciones resolutivas que sean necesarias,
mejorando así la calidad de los futuros servicios.
• El seguimiento realizado por este proceso permite identificar fallos en los
servicios motivados por acciones de los usuarios, pudiendo definir acciones
de mejora, como por ejemplo, la formación.
• La actividad de gestión de nivel de servicio refuerza la gestión y relación con
las áreas internas de TI y con los suministradores externos gracias a su inte-
gración en la cadena de aseguramiento de los SLA de los clientes, “todos tie-
nen un objetivo común”.
• Los SLA constituyen el elemento básico para poder realizar la facturación de
los servicios TI a los clientes según los niveles de servicio requeridos.
• ¿Cuál es la estructura del catálogo de servicios de su organización
deTI?
• ¿Cuál es la estructura de los SLA de su organización?
• ¿Cómo están estructuradas internamente las unidades o grupos de su
departamento de TI de cara a la realización de OLA?
1
6.2. Generación de informes del servicio 237
6.2. Generación de informes del servicio
Figura 6.2.1. Esquema general del proceso de generación de informes de servicio
Caídas de los servicios, cambios en los servidores, compras de equipamiento nuevo,

miles de peticiones de los usuarios, etc. La vida cotidiana en las “calderas” de la ges-
tión de las tecnologías de la información está llena, quizás demasiado, de actividad.
La sobreocupación de la organización de TI atendiendo el día a día lleva a pensar
que únicamente con aguantar el ritmo de trabajo es suficiente, pero no es así, es
necesario, además, mantener un flujo constante de comunicación e información
con toda la organización sobre los logros que se consiguen y el funcionamiento de
los servicios. Sin esta comunicación, la insatisfacción de las áreas de negocio con TI
está garantizada (véase la figura 6.2.1).
Una buena disciplina en la generación de informes y el mantenimiento de una
comunicación constante, ayudará a la comprensión mutua. La primera frase que
se escucha al acercarse al mundo de las métricas y de la calidad es “todo lo que no se
puede medir no existe” y aunque es un poco drástica, pone claramente el foco en la
necesidad de medir los múltiples componentes y resultados de la actividad de TI.
El mundo técnico tiende a ningunear la actividad de generación de métricas e
informes, viendo esta tarea como una sobrecarga burocrática a su trabajo diario.
En el ámbito de las Normas ISO/IEC 20000 se aporta una solución práctica para
intentar atajar este mal endémico, centralizando toda la actividad de generación de

informes en un proceso. Éste recopila las necesidades de los clientes del resto
de procesos y, en general, de toda la organización de TI, para impulsar la definición y
creación de todos los informes necesarios.
Por si fuera poco, las carencias no sólo provienen de las capas técnicas. Con fre-
cuencia es la propia dirección la que primeramente solicita los informes para poste-
riormente no utilizarlos en la gestión diaria y en la toma de decisiones. A nivel
directivo, las decisiones muchas veces se toman por intuición, derivadas de una cri-
sis o por visión estratégica, ignorándose reiteradamente la valiosa información
aportada por los informes.
Si bien la información es útil para la toma de decisiones, también debe notarse cla-
ramente su uso y toda la organización lo debe percibir. De esta forma, los comités
regulares de dirección de TI deberían comenzar con un análisis de los principales
indicadores, para continuar con el estado de los principales proyectos y el avance
de las iniciativas estratégicas de transformación. A partir de este momento, conti-
nuar con los incidentes más graves y con el resto de la agenda. En este escenario, la
información aporta valor y es rentable el esfuerzo de producirla.
En las empresas que han alcanzado la excelencia en su gestión, las decisiones se
toman con base en las métricas y los informes, respaldando la visión y la intuición
de la dirección. Así, unas decisiones basadas en indicadores podrían ser:
• Se desencadena una iniciativa de reducción de costes porque el ratio de coste
de TI por usuario es más alto que el benchmarking realizado contra el mer-
cado. También se respalda esta iniciativa porque el ratio de coste global de
TI en relación a la facturación de la empresa (ITR, IT Spending per unit of
Revenue) es mayor que el de empresas equivalentes o del mismo segmento.
• Se lanza un proyecto de transformación de arquitectura y plataforma tecno-
lógica, porque la tasa de incidentes por usuario es alta como consecuencia de
una infraestructura demasiado inestable.
• Se refuerza el equipo de gestión del problema debido a que, en el último
semestre, el 30% de las incidencias producidas son repetitivas y originadas
por las mismas causas.
• Se crea una dotación presupuestaria para una iniciativa de renovación de la
planta de ordenadores PC, porque el indicador de obsolescencia del parque
de ordenadores personales es alto y, como consecuencia, la productividad del
empleado habrá ido disminuyendo.
• Se lanza una campaña de comunicación al ver que ha descendido el indica-
dor que mide la satisfacción de los clientes y usuarios con TI.
• Se implanta una política de teletrabajo para flexibilizar los horarios, al resul-

tar muy baja la satisfacción del empleado de TI en la última encuesta anual.
En la figura 6.2.2 se presenta una visión introductoria al proceso de generación de

informes del servicio.
Proceso de generación de Qué aporta:

informes del servicio • Al centralizar en un proceso la
generación de informes, se obtiene
una visión homogénea sobre TI.
Definición: • Se asegura que todos los informes se
Proceso que centraliza la generación adecuen a las necesidades de TI.
de todos los informes de TI con el • Se cubren todas las necesidades
fin de que sean homogéneos, útiles y de informar y comunicar.
entendibles por los destinatarios. • La información es fiable.
• La información es claramente
entendible por los destinatarios.
Objetivo:
• Centraliza todos los indicadores y
Generar en plazo los informes mediciones de TI.
acordados, fiables y precisos, para • Aumenta la productividad en la
informar a la toma de decisiones y generación de informes.
para una comunicación eficaz.
• Hay un responsable que vela por la
generación de informes en plazo,
forma y calidad.
Figura 6.2.2. Introducción al proceso de generación de informes del servicio
Para que la gestión del servicio aporte valor real a la organización de TI y al nego-
cio, debe disponer en tiempo y con calidad de la información que permita la
correcta toma de decisiones. La centralización de todos los informes en un único
punto aporta grandes ventajas en la realización de esta labor incomprendida, pues
responsabiliza a un proceso de la definición general de las políticas de informes y
de su generación. Los informes deben ser fiables, precisos y entregados a tiempo.
Los informes de TI destinados al negocio deben contener medidas significativas y
entendibles por él que permitan ayudarle a alcanzar sus objetivos estratégicos. La
precisión y fiabilidad de los valores aportados son clave en la relación con el cliente.
Asimismo, la puntualidad en la entrega de los informes de nivel de servicio, según
lo comprometido en los SLA, junto con los aspectos reseñados anteriormente,
aportan confianza al cliente en la relación.
Los indicadores de disponibilidad, rendimiento y capacidad son, sin lugar a dudas,

los más importantes para la operativa de TI, y sus valores permiten una monitori-
zación de la calidad del servicio. Pero no son los únicos. También hay otros muy
importantes: la alineación con los estándares, el cumplimiento de la legislación, la
seguridad, la eficiencia operativa, etc.
Los datos recogidos deben permitir la generación de informes reactivos, proactivos
y el análisis de las tendencias principales.
La frecuencia en la obtención de la información también debe adecuarse a su utili-
zación, en unos casos se tiene que proporcionar en el rabioso tiempo real (instantá-
neo o inmediato), mientras que en otros sólo se necesitará con periodicidad men-
sual o anual.
Es recomendable que el contenido de los informes refleje el resultado de la compa-
ración entre los valores de los indicadores obtenidos y los valores objetivo o umbra-
les de referencia comprometidos. Aunque, en la etapa de implementación de un
indicador, lo habitual es realizar unas mediciones para conocer lo que está pasando
sin tener predefinido un valor objetivo de referencia.
Los informes pueden estar destinados al negocio o bien a la propia gestión interna.
En el primer caso se cuidará de mantener el idioma y visión del negocio. En los
informes internos, primará la información técnica y las tendencias evolutivas.
Los informes forman parte del conocimiento de la organización. Por ello se debe-
rán incorporar el sistema de información y documentación estructurado en TI, sis-
tema que se convertirá en el instrumento online de trabajo para toda la organiza-
ción.
La disciplina de generación de informes debe tener en cuenta cuatro principios
básicos, mostrados en la figura 6.2.3.
La fiabilidad de la información contenida en los informes es uno de los factores
más esenciales, en su generación se debe velar especialmente por la calidad de los
datos mostrados. Sin una información fiable, no tendrá utilidad alguna la actividad
de generarlos.
Por otra parte, es importante que los informes sean claros y fácilmente entendibles
por sus destinatarios. La estructura a contemplar en los informes muy técnicos es
diferente a los informes orientados al negocio o la dirección. Cada uno de ellos
debe adaptarse a la cultura y los hábitos de los destinatarios.
En todos los informes se debe mantener una “línea de estilo” o línea editorial que
facilite su comprensión por los lectores. Los gráficos, escalas, tamaños, colores,
etc., deben mantener una coherencia entre unos informes y otros, para que se pue-
dan interpretar más fácilmente.
Figura 6.2.3. Principios básicos de la generación de informes
Los informes deben mantener una continuidad a lo largo del tiempo, represen-
tando conceptos similares y su evolución histórica. Para ello, disponer de un repo-
sitorio con todos los indicadores y sus mediciones será una de las primeras activi-
dades que se deben realizar. Para la creación de este repositorio o base de datos hay
varias alternativas, como utilizar la solución que habitualmente incorporan las
herramientas de gestión del servicio o como crear uno nuevo utilizando las herra-
mientas habituales de análisis de datos e inteligencia de negocio (data warehouse,
data mart, extracción de datos, etc.). En organizaciones pequeñas se puede empe-
zar con una simple hoja de cálculo.
Es importante que los informes reflejen la evolución histórica de los indicadores
que contienen, pues en la gestión del servicio de TI son tan esenciales las tenden-
cias como los valores puntuales de un período.
Los informes deben entregarse a tiempo, en el momento en que se necesiten, para
conocer la situación o para tomar decisiones. Para conseguirlo es necesario dispo-
ner de las herramientas adecuadas que faciliten la laboriosa tarea de su confección.
El cumplimiento sistemático en las fechas de entrega de los informes permitirá que
las decisiones se tomen a tiempo y marcará una pauta rítmica de trabajo en toda la
organización.
En la figura 6.2.4 se muestran los componentes principales del proceso.
COMPONENTES DE GENERACIÓN DE INFORMES
Hechos
ocurridos Niveles
de servicio
Cuadros
de mando
Política Diseño de
de informes informes Realización Informes
de informes
KGI
Panel de
control
KPI
Indicadores
Arquitectura
de métricas
Monitorización
Base de datos de
indicadores y mediciones
Figura 6.2.4. Componentes principales del proceso de generación de informes
Arquitectura de métricas. Es un documento que analiza y estructura por niveles todos

los indicadores necesarios para la gestión de TI. Para cada indicador se define una ficha
de detalle. En organizaciones maduras suele contener más de 200 indicadores.
Base de datos de indicadores y mediciones. Es una base de datos que contiene la

definición de cada uno de los indicadores (fichas) y el histórico de las mediciones de
cada uno de los indicadores. Es la base fundamental para la generación de informes.
Cuadro de mando integral (BSC, Balanced Score Card). Término difundido por
Kaplan y Norton para mostrar el estado de una empresa en base a objetivos e indi-
cadores agrupados en cuatro perspectivas: económica, cliente, interna y crecimiento.
Cuadro de mando de TI. Conjunto de indicadores que muestran una visión glo-
bal del estado de TI. Contiene indicadores globales. Resume en un informe los
indicadores más relevantes sin respetar las cuatro perspectivas clásicas de Kaplan y
Norton.
Dato, información y conocimiento. Un dato es un conjunto discreto, de valores

objetivos sobre un hecho real. Un dato no dice nada sobre el porqué de las cosas y,
por sí mismo, tiene poca o ninguna relevancia o propósito.
La información es un mensaje, normalmente bajo la forma de un documento o
algún tipo de comunicación audible o visible. A diferencia de los datos, la informa-
ción tiene significado (relevancia y propósito). No sólo puede formar potencial-
mente al que la recibe, sino que está organizada para algún propósito. Los datos se
convierten en información cuando su creador les añade significado. Transforma-
mos datos en información añadiéndoles valor en varios sentidos.
El conocimiento es una mezcla de experiencia, valores, información y “saber hacer”
que sirve como marco para la incorporación de nuevas experiencias e información,
y es útil para la acción. Se origina y aplica en la mente de los conocedores. En las
organizaciones, con frecuencia no sólo se encuentra dentro de documentos o alma-
cenes de datos, sino que también esta en rutinas organizativas, procesos, prácticas,
y normas.
Factor crítico de éxito (CSF, Critical Success Factor). Término utilizado en el

ámbito de ITIL para definir un aspecto crítico o esencial a tener en cuenta para
el éxito en un proceso.
Hechos ocurridos en el período. Sucesos ocurridos, actividades realizadas y

hechos relevantes a tener en cuenta en los informes.
Histórico del servicio. Representación de los valores de los indicadores de un

servicio y comprende generalmente uno o más años si bien el período de retención
dependerá de la naturaleza del indicador o métrica considerada.
Indicador o métrica. Son datos. Los términos de indicador y métrica se utilizan

normalmente como sinónimos y representan un tipo de dato utilizado para medir
una característica de TI. Los indicadores se definen en una ficha y se miden.
Indicador objetivo (KGI, Key Goal Indicator). Indicador que muestra una caracte-
rística clave o general. Término utilizado en COBIT. Se utiliza para determinar los
indicadores más importantes de TI (por ejemplo, el tiempo que se tarda en crear
un nuevo servicio de TI o “time-to-market”). Dado que la organización de TI suele
estar dividida por lo menos en tres áreas (desarrollo, sistemas o centro de proceso
de datos y microinformática o puesto de trabajo), los KGI se agrupan a su vez en:
• KGI-TI. Indicador objetivo general o común a todo el área de TI o indica-
dor de gobierno de las TI.
• KGI-CPD. Indicador objetivo del área de explotación de sistemas o del cen-
tro de proceso de datos (CPD).
• KGI-PT. Indicador objetivo del área del puesto de trabajo (PT) formado por
microinformática más las redes.
• KGI-DES. Indicador objetivo del área de desarrollo de aplicaciones.
Indicador de rendimiento (KPI, Key Performance Indicator). Indicador que mide

el desempeño o rendimiento de un proceso, de un proyecto, etc. (por ejemplo, el
“número de problemas abiertos”). Es un indicador más de detalle que el KGI.
Informe. Es un documento impreso o electrónico que contiene indicadores, análi-

sis e información sobre un ámbito determinado de TI.
Informe del servicio. Es un informe sobre los servicios que presta TI indicando
el grado de cumplimiento de los niveles de servicio, los hechos más relevantes en el
período con relación al servicio (incidentes, problemas, evolución, etc.).
Medida. Es el valor medido en un instante determinado de un indicador o métrica.

Las medidas de un indicador se deben almacenar en un histórico para su trata-
miento posterior. En este proceso medida y medición se utilizan como sinónimos.
Niveles de servicio. Son los valores mínimos o máximos de los indicadores pacta-
dos con el cliente que deben cumplir los servicios de TI prestados.
Políticas de informes. Documento que establece los principios que deben cumplir
los informes de una organización.

En ISO/IEC 20000 se centralizan en este proceso las actividades de generación de
todo tipo de informes con el fin de aportar una visión conjunta de la información y
de controlar su calidad y su generación a tiempo. Esta centralización tiene todo su
sentido, ya que los informes se sustentan en gran parte en los indicadores, que
deben definirse y recopilarse bajo una visión común.
En este apartado se desarrollan ampliamente los algo escuetos requisitos plantea-

dos en las Normas ISO/IEC 20000, recomendándose un conjunto de actividades
necesarias para el éxito del proceso. Por tanto, estas actividades y su desarrollo van
más allá de los requisitos contenidos en estas normas.
La gestión de informes debe trabajar completamente coordinada con los responsa-
bles de los procesos y de las grandes áreas de TI, pues necesita de su participación
para conocer la actividad diaria que realizan y conseguir que éstas realicen un análi-
sis adecuado de los valores obtenidos. Las interacciones y funcionalidades de gene-
ración de informes de servicio se resumen en la figura 6.2.5.
Desencadenantes 3 Definición de la política de Salidas principales:

del proceso: informes. Ü Cuadros de mando.
Ü Llegada de la fecha 3 Definición de la arquitectura Ü Informes del servicio.
preparación del de métricas.
Ü Panel de control.
informe. 3 Diseño de los informes tipo.
Ü Otro tipo de informes.
Ü Petición expresa de la 3 Implementación de
dirección. Ü Políticas de informes.
herramientas: monitorización,
recogida y reporting.
Entradas de soporte: Salidas secundarias:
3 Captura de indicadores.
Ü Acuerdos de nivel de Ü Base de datos de
servicio existentes. 3 Generación de informes. indicadores y mediciones
3 Distribución de informes. actualizada.
Ü Estrategias del negocio y
de TI. 3 Supervisión funcionamiento Ü Arquitectura de
del proceso. Mejora del métricas.
Ü Datos de benchmarking
del mercado. propio proceso. Ü Informes tipo o
plantillas.
Ü Alarmas de umbrales
sobrepasados.
Figura 6.2.5. Entradas, actividades y salidas del proceso
Las principales entradas que desencadenan el proceso son la proximidad de la fecha

en la que en informe debe estar publicado (semanal, mensual, trimestral o anual)
que activa las acciones para la confección del informe; y una petición expresa de
la dirección de TI sobre la necesidad de disponer de un informe determinado
(previsto o nuevo).
Las entradas de soporte que utiliza el proceso son los acuerdos de nivel de servicio,
que informan sobre los umbrales que se utilizarán en los informes; las estrategias
del negocio y de TI, para la confección de la arquitectura de métricas y el diseño de
los informes tipo; datos externos de benchmarking del mercado con ratios compara-
tivos, con el fin de comparar los valores de los indicadores internos con los externos.
Las salidas principales del proceso son: los cuadros de mando actualizados necesa-
rios (global de TI, del CPD, del Puesto, de Desarrollo, etc.); los informes del servi-
cio prestado; el panel de control de TI; otros tipos de informes sobre acciones, pro-
yectos, iniciativas, etc.; las políticas de informes generadas que marcan las
directrices del proceso.
Como salidas secundarias del proceso destacan: la base de datos de indicadores y
mediciones actualizada, el repositorio generado por el proceso que almacena los
datos necesarios para la confección de los informes; la propia arquitectura de métri-
cas creada y actualizada; las diversas plantillas que conforman los informes tipo; las
alertas generadas por haberse sobrepasado los umbrales de nivel de servicio, etc.
Las actividades del proceso son:
Definición de la política de informes. En la que se define el alcance del proceso,
las responsabilidades sobre los datos y los informes, su difusión, etc.
Definición de la arquitectura de métricas. Realizada partiendo de la estrategia

del negocio y de la estrategia de TI, que define un conjunto de indicadores estruc-
turados que son la base para los informes.
Diseño de los informes tipo. En una organización de TI eficiente, los informes se

deben predefinir de tal forma que se diseñen una vez y se ejecuten en serie. La
información contenida en todos los informes debe mantener un estilo homogéneo
para que sean más sencillos de entender. Como resultado de esta actividad se obtie-
nen las plantillas de los diversos tipos de informes a utilizar, adaptados al destinata-
rio, el medio de difusión y la frecuencia.
Implementación de las herramientas. La generación de informes se inicia con la

monitorización que realiza la captura de los indicadores y los almacenan en sus
archivos específicos (por ejemplo, archivos de log), que luego hay que recoger e
importar en la base de datos de mediciones. Por último, existe un conjunto de fun-
cionalidades de reporting que permiten generar informes bajo demanda. Se deben
definir y desarrollar los sistemas para la captura de información y su correspon-
diente correlación para obtener las medias adecuadas para la generación de infor-
mes. En este escenario las herramientas juegan un papel fundamental para facilitar
el trabajo y evitar errores. Las herramientas comprenden:
• Las consolas de monitorización.

• La captura de información en la base de datos central.
• La generación de informes.
• Navegación desde una visión del servicio por los elementos que lo compo-
nen, conociendo su estado en tiempo real.
• La generación y publicación de cuadros de mando y paneles de control.
Hay que señalar que en numerosos casos, la implementación de éstas y otras herra-
mientas requeridas por el proceso de generación de informes de servicio se limitará
a establecer las interfaces con las herramientas ya implementadas dentro de otros
procesos (un caso general es la integración con las herramientas de monitorización
y operación).
Captura de Indicadores. En esta actividad se realiza la recopilación de toda la

información disponible en forma de indicadores y métricas durante el periodo de
reporte. Esta información procede fundamentalmente de la actividad de los proce-
sos de gestión de servicio:
• Gestión de nivel de servicio.
• Gestión de incidencias (asociados a un SLA).
• Gestión de la capacidad (disminución de la carga de trabajo).
• Gestión de la disponibilidad (mejora de la disponibilidad y fiabilidad).
• Gestión financiera (tarifas aplicables y coste real de los servicios).
• Etc.
Generación de informes. En esta actividad se generan los informes con los resul-
tados de los indicadores o métricas obtenidas. Los informes deben ser útiles y no
unos meros portadores de datos. Por ello, además de los datos, deben incorporar
análisis de la información, revisión de los resultados obtenidos, descripción de los
hechos relevantes en el período, etc. (aunque estos análisis, en muchos casos, este
proceso sólo se encargue de hacer que otros lo realicen). Como resultado de esta
actividad y, en función del destinatario y la periodicidad establecida, se generan los
informes del servicio. También es clave que los informes reflejen el resultado de la
comparación entre los valores de indicadores obtenidos y los valores objetivo o
umbrales de referencia.
La generación de informes toma como punto de partida los datos ya recopilados
en la base de datos de indicadores y mediciones, y de los informes tipo, para la
generación de los informes. En una primera fase, el proceso genera los informes en
modo borrador, para que sean completados y comentados por cada uno de los pro-
cesos o áreas involucradas. Por ello, esta actividad debe perseguir a los responsables
para que revisen y complementen con información estos borradores.
Distribución de informes. Una vez generados los informes se deben distribuir a

los destinatarios previstos. La forma más sencilla o inmediata de realizar la distri-
bución es subir el informe a una sección de informes en el portal web de TI y
comunicar a los destinatarios por correo electrónico su disponibilidad, si bien el
mecanismo que se debe utilizar vendrá marcado en gran medida por la criticidad
de la información. En el caso de tratarse de informes a las áreas clientes o a la direc-
ción, será conveniente mantener una reunión o audioconferencia para explicarlos y
revisarlos en detalle. En estas revisiones convendría contar con la presencia de los
responsables de los procesos tratados en el informe, y si es a los clientes, también
del gestor de relaciones con el negocio (gestor del cliente).
Supervisión del funcionamiento del proceso y mejora del mismo. Al igual que
en resto de procesos, el responsable del proceso debe supervisar la eficacia del pro-
ceso, la calidad de los datos contenidos y la entrega a tiempo de los informes.
Una de las facetas importantes de esta actividad es comprobar y conseguir que los
informes sean utilizados por sus destinatarios y que cumplan su misión de infor-
mación, seguimiento o ayuda a la toma de decisiones para los que fueron creados.
Es también responsabilidad de esta actividad impulsar en los otros procesos la
generación de los planes de mejora derivados del análisis de los informes. Un ejem-
plo claro de esto es el proceso de gestión de nivel de servicio, que vela por que se
subsanen de forma inmediata las roturas de niveles de servicio detectadas en los
informes, desarrollando las iniciativas de mejora. Además, dado que los informes
llevan también integrada la tendencia de evolución de los indicadores, se podrá
detectar anticipadamente el riesgo de incumplimiento de los niveles de servicio
para adoptar las medidas proactivas necesarias.
Todas las mejoras detectadas se incorporarán al plan general de mejora de TI, sin
que por ello, se dejen de ejecutar las acciones correctoras inmediatas.
Política de la generación de informes de servicio

En la Norma ISO/IEC 20000-2 se establecen recomendaciones para la definición
de una política de generación de los informes, estableciéndose que se acuerden y
registren los requisitos para la generación de informes.
UNE-ISO/IEC 20000-2
Política
Los requisitos para la generación de infor- tradores subcontratados por éstos, los
mes para clientes y para gestión interna informes deberían reflejar las relacio-
se deberían acordar y ser registrados. nes entre ellos. Por ejemplo, un sumi-
nistrador principal debería informar
La supervisión del servicio y la genera-
sobre la totalidad del servicio que
ción de informes abarcan todos los
presta, incluyendo cualquier servicio
aspectos medibles del servicio, propor-
realizado por un tercero y que forme
cionando datos actuales e históricos.
parte del que el suministrador principal
Cuando existan múltiples proveedores, gestiona como parte del servicio al
suministradores principales y suminis- cliente.
Las fuentes de información y de conocimiento en TI

Antes de continuar con los indicadores y los informes conviene reflexionar breve-
mente sobre los diversos tipos de información y conocimiento existentes en TI.
Pues no todo el conocimiento de TI se obtiene de los indicadores, ni toda la infor-
mación para la toma de decisiones se incluye en los informes del servicio. Estas dis-
tinciones son importantes para evitar sobrecargar los informes con indicadores,
cuando la información se debe obtener de otras fuentes. En general, el conoci-
miento en TI proviene de:
• Información no escrita: conocimiento histórico, conversaciones informales,
temas tratados en reuniones, etc.
• Información descriptiva textual: arquitecturas, inventarios, informes,
manuales, procedimientos, comunicados, correo electrónico, etc.
• Información de seguimiento de la actividad: planificaciones, informes de
avance, cumplimiento de hitos, etc.
• Información sobre el servicio: informes, notificaciones y escalados, actas.
• Información creada ad-hoc para una necesidad: auditorías, informes de con-
sultoras, planes de evolución, tendencias mercado, benchmarking, etc.
• Información sobre volumetrías de TI: estadísticas diversas, volúmenes inven-
tariados, volúmenes de actividad y de planta, etc.
• Información en tiempo real: proveniente de la monitorización y de los even-
tos surgidos.
• Métricas e indicadores, cuadros de mando.

• Conocimiento especialista: de la tecnología en general, de unas instalaciones
concretas, etc.
La tipificación del conocimiento utilizado en TI permitirá tener una visión panorá-

mica más clara que discierna entre conocimiento, información y métricas. En la
figura 6.2.6 se muestra una tipificación de la información en dos ejes que permiten
clasificarla entre su uso para el gobierno (estrategia y decisión) o la gestión (ejecu-
ción y seguimiento), junto a una visión sobre si la información que contiene es des-
criptiva (cualitativa), o más bien está basada en cifras (cuantitativa).
Cuadros
Tendencias de mando
Benchmarking
Gobierno
Informe mensual
ejecutivo
Verbal
Texto mail Informes del servicio
Métricas servicio
Gestión
Alertas
Inventarios
Documentación Monitorización
Cualitativa Cuantitativa
Figura 6.2.6. Tipificación del conocimiento acerca de TI

Por tanto, para la toma de decisiones y para el conocimiento de TI no es suficiente

con los indicadores, ni con los informes del servicio. Se debe recurrir también a
otro tipo de información, interna y externa. Por ello, en la definición de los indica-
dores necesarios, se debe tener presente este hecho y no intentar cubrir en base a
indicadores todo el conocimiento sobre TI.
Los indicadores son una parte esencial de los informes

Los informes en TI versan sobre la actividad propia y los resultados de los servicios
ofrecidos a los clientes. Por ello, los informes se sustentan en indicadores y métri-
cas representados en diversos tipos de gráficos.
Los indicadores o las métricas son el núcleo esencial de los informes. El objetivo de
los indicadores es aportar una visión del estado de TI y del cumplimiento de los
objetivos marcados. No obstante, de acuerdo con lo descrito en el punto anterior,
hay que considerar que los indicadores son un instrumento parcial que aporta una
idea aproximada de la realidad y, además, pueden ser manipulados en función de
los resultados que interese presentar.
Las métricas y los informes se suelen agrupar en niveles o capas según el público
destinatario de los mismos. De forma general se estructuran en estratégicos, tácti-
cos u operativos (inspirado en COBIT). A continuación se presenta una visión sim-
plificada de estos tres niveles:
• Indicadores estratégicos. Contienen información para la toma de decisio-
nes de alto nivel. Dado que en organizaciones grandes, TI suele estar divi-
dida en diferentes áreas (por ejemplo, desarrollo, centro de datos y puesto de
trabajo), se ha considerado útil desglosar los indicadores e informes estraté-
gicos en dos: los globales con una visión conjunta de todo TI y los especí-
ficos de estas áreas:
– Estratégicos y globales de TI (KGI, Key Goal Indicator, de TI). Mues-
tran información general sobre TI y su desempeño. Estos indicadores for-
man parte del cuadro de mando general de TI. Estos indicadores sobre los
objetivos están vinculados con el cuadro de mando general de la empresa
y se utilizan también para mostrar al negocio y a la dirección de la empresa
(CEO) los resultados de TI.
Ejemplos de KGI de TI pueden ser la disponibilidad de los servicios de
TI, el coste de TI por usuario, la madurez en la gestión de TI, el time-to-
market medio de cambios, el porcentaje de cambios en plazo o la satisfac-
ción de los clientes y usuarios con TI.
– Estratégicos y por área de TI (KGI de área). Además, también se suelen

definir los indicadores globales de un área que son indicadores también de
alto nivel pero centrados en una de las grandes unidades o áreas que sue-
len componer TI, como por ejemplo, desarrollo, puesto de trabajo, pro-
ducción del centro de datos, planificación y control, etc. Componen un
cuadro de mando específico de este área y contribuyen al cuadro de mando
general de TI.
• Indicadores tácticos o globales de proceso (KGI de proceso). Muestran

una información resumida del desempeño de cada proceso. Se suelen definir
entre 3 y 5 indicadores de objetivos por cada proceso. Estos indicadores los
utiliza el responsable del proceso para mostrar a la dirección de TI (CIO) la
contribución de su proceso al éxito de TI.
Ejemplos de KGI de proceso son: el porcentaje de incidentes resueltos en
plazo, los incidentes resueltos en primera línea, el número de soluciones tem-
porales activas, el porcentaje de elementos de configuración con actualización
automatizada, el porcentaje de objetivos de SLA incumplidos o los costes de
provisión por servicio.
También debe haber otro tipo de indicadores de objetivos, más allá de los
procesos, por ejemplo, los indicadores de evolución de los proyectos (tanto
de desarrollo, como de producción), el avance de las iniciativas estratégicas de
transformación de TI, los indicadores sobre el estado de la plataforma tecno-
lógica, sobre los RRHH, sobre el ámbito financiero, etc.
• Indicadores operativos o de rendimiento (KPI, Key Performance Indicator).

Indicador que muestra una faceta del comportamiento de una función o acti-
vidad de TI. Unos buenos indicadores de rendimiento (KPI) apalancarán la
obtención de unos buenos indicadores globales o de objetivos (KGI), aunque
no hay una relación matemática entre ellos. Habitualmente suelen identifi-
carse entre 10 y 20 indicadores de rendimiento por proceso. Los principales
indicadores de rendimiento que se suelen medir son:
– KPI de los procesos de TI: número total de incidentes, número de pro-
blemas abiertos, número de reuniones con clientes al mes, etc.
– KPI de los proyectos de TI: proyectos en plazo, tiempo medio de desvia-
ción de los proyectos, etc.
– KPI de las iniciativas estratégicas de TI: iniciativas en plazo, objetivos
alcanzados, etc.
– KPI sobre la tecnología, etc.
En la figura 6.2.7 se muestra esta estructura por capas y el ámbito de cada indica-
dor (arquitectura de métricas) y su relación con los informes asociados.
Figura 6.2.7. Estructura por niveles de los indicadores y

su contribución a los informes
En esta representación de indicadores en cascada, no quiere decir que los indicado-

res superiores se calculen como una media ponderada de los indicadores inferiores.
Sencillamente muestran algún aspecto más general (por ejemplo, la disponibilidad
de los servicios, el coste total por usuario, etc.).
Esta misma estructuración en pirámide de tres capas se ha utilizado en este libro al
final de cada proceso para categorizar los indicadores recomendados de proceso.
Estos indicadores se recomiendan como parte de la arquitectura de métricas. En la
figura 6.2.8 se muestra el esquema de órbitas alrededor de un proceso utilizado
para representar los indicadores.
Figura 6.2.8. Representación en tres niveles de los indicadores de

los procesos utilizada en este libro
Metodología para la definición de una arquitectura

de métricas
Con el fin de tener un control de la actividad, una organización de TI madura suele
identificar cerca de 200 indicadores. Además, cada uno de estos indicadores es la
suma de un conjunto de mediciones, sobre los servicios, sobre los componentes,
etc., lo que conlleva la necesidad de automatizar con herramientas de monitoriza-
ción la captura de indicadores para poder gestionar el alto volumen de mediciones.
Por tanto, se necesita bastante estabilidad en el conjunto de indicadores que se van
a medir, que hay que conjugar con la necesidad cambiante de información precisa
sobre los objetivos definidos cada año.
De cara a mantener una base estable de indicadores que pueda ser utilizada en los
informes y en la gestión de TI, es recomendable realizar un ejercicio de definición
de un conjunto más amplio de indicadores que se puedan necesitar en un docu-
mento, aquí denominado “arquitectura de métricas”.
En la definición de la arquitectura de métricas se suele utilizar una mezcla de tácti-
cas iterativas hasta que se alcanza un mapa de indicadores, con los que se tendrán
controlados los servicios y el desempeño de TI. Las técnicas principales utilizadas
en la definición de esta arquitectura son:
• Intuitiva. Cada miembro expresa de forma intuitiva las métricas que consi-
dera más relevantes. La visión intuitiva es muy importante y se utiliza varias
veces en el ciclo de definición del mapa de indicadores.
• En base a un mix de experiencias (propias y ajenas). La experiencia y la
historia de los indicadores internos y los aportados por organizaciones exter-
nas, conforman la base para la primera propuesta.
• Seguimiento de COBIT al 100%. En este caso se toma el estándar COBIT
y de él se extraen indicadores.
• Seguimiento de ITIL al 100%. Al igual que en el caso anterior, ITIL se
toma como la única referencia.
• Mix de modelos: ITIL + COBIT. Se toman los procesos ITIL como base, y
se buscan indicadores proporcionados tanto por ITIL como por COBIT, o
bien que resulten complementarios a efectos de completitud de la información.
• Alineación con el negocio. El eje conductor de todo el ejercicio de selec-
ción de indicadores se articula en torno a la estrategia del negocio, identifi-
cando los objetivos de la empresa y los objetivos definidos de TI.
De cara a abordar un proyecto de definición de la arquitectura de métricas de TI,

se recomienda utilizar una metodología mixta que contemple de alguna forma las
técnicas anteriores. En la figura 6.2.9 se muestra una metodología para la defini-
ción de un mapa o una estructura de métricas en TI.
Fuente: Quint Group y Telefónica.
Figura 6.2.9. Metodología ejemplo para la creación de una arquitectura de métricas

En la Etapa I se identifica la estrategia de negocio existente y se establece una lista

de 4 ó 5 objetivos de la empresa. Para ello, COBIT aporta cierta ayuda al tipificar
los diferentes objetivos corporativos (que marcarán los posibles objetivos de TI
dentro de la Etapa IV). En la figura 6.2.10 se muestra la tabla de objetivos de
TI de COBIT.
Perspectiva BSC
Tipos de objetivos de negocio en COBIT
del negocio
1 Expandir el porcentaje de mercado.
2 Aumentar el ingreso.
Perspectiva
3 Retorno sobre la inversión.
financiera
4 Optimizar el uso de recursos.
5 Administrar los riesgos del negocio.
6 Mejorar la orientación y el servicio al cliente.

7 Ofrecer productos y servicios competitivos.
Perspectiva
8 Disponibilidad del servicio.
del cliente
9 Agilidad para responder a los requisitos cambiantes (tiempo para
comercializar).
10 Optimización del coste de prestación del servicio.
11 Automatizar e integrar la cadena de valor empresarial.

12 Mejorar y mantener la funcionalidad del proceso de negocio.
13 Disminuir los costes de los procesos.
Perspectiva
14 Cumplimiento de leyes y reglamentos externos.
interna
15 Transparencia.
16 Cumplimiento de políticas internas.
17 Mejorar y mantener la productividad operativa del equipo de trabajo.
18 Innovación del producto/negocio.

Perspectiva de
19 Obtener información confiable y útil para la toma de decisiones
aprendizaje
estratégicas.
y crecimiento
20 Adquirir y mantener personal capacitado y motivado.
Fuente: COBIT 4.0.
Figura 6.2.10. Tabla de objetivos posibles del negocio tipificados en COBIT
Se pasa a la Etapa II, en la que se identifica la estrategia seguida por TI. Igualmente
el resultado es una lista corta de objetivos de TI. En la figura 6.2.11 se muestran
los objetivos tipificados en COBIT para los objetivos de TI.
ID. Objetivos TI – COBIT
1 Responder a los requerimientos del negocio en alineación con la estrategia del negocio.
2 Responder a los requerimientos de gobierno en línea con el consejo de dirección.
3 Asegurar la satisfacción de los usuarios finales con los servicios y niveles de servicio ofrecidos.
4 Optimizar el uso de la información.
5 Crear agilidad en TI.
6 Determinar cómo las necesidades funcionales y de control del negocio son traducidas en soluciones
automáticas efectivas y eficientes.
7 Adquirir y mantener sistemas y aplicaciones estandarizados.
8 Adquirir y mantener infraestructuras de TI integradas y estandarizadas.
9 Adquirir y mantener técnicas en TI que respondan a la estrategia de las TI.
10 Asegurar la mutua satisfacción en la relación con terceros.
11 Integrar perfectamente aplicaciones y soluciones tecnológicas dentro de los procesos de negocio.
12 Asegurar la transparencia y comprensión de los costes, beneficios, estrategias, políticas y servicios de TI.
13 Asegurar el correcto uso y funcionamiento de las aplicaciones y soluciones tecnológicas.
14 Responder por todos los activos de TI y protegerlos.
15 Optimizar las infraestructuras, recursos y capacidades de TI.
16 Reducir los defectos y adaptaciones en las entregas de soluciones y servicios.
17 Proteger la consecución de los objetivos de TI.
18 Establecer con claridad el impacto en el negocio de los riesgos en los objetivos y recursos de TI.
19 Asegurar que la información crítica y confidencial está protegida de aquellos que no deben tener acceso
a ella.
20 Asegurar que las transacciones del negocio automatizadas y los intercambios de información pueden ser
realizadas correctamente.
21 Asegurar que los servicios e infraestructuras de TI pueden resistir y recuperarse correctamente de fallos
debidos a errores, ataques deliberados o desastres.
22 Asegurar el mínimo impacto en el negocio en caso de una interrupción o cambio en los servicios de TI.
23 Comprobar que los servicios de TI están disponibles cuando se les requiera.
24 Mejorar la relación costes-eficiencia en las TI (rentabilidad) y su contribución a los beneficios del negocio.
25 Entregar los proyectos en tiempo y presupuesto cumpliendo con los estándares de calidad.
26 Mantener la integridad de la información e infraestructura de proceso.
27 Asegurar la conformidad de TI con leyes y regulaciones.
28 Asegurar que TI da servicios de calidad con una demostrada eficiencia en costes, mejora continua y
preparación para cambios futuros.
Fuente: COBIT 4.0.
Figura 6.2.11. Tabla de posibles objetivos de TI tipificados en COBIT
En la Etapa III, se realiza el cuadre entre las estrategias del negocio y las estrategias
de TI. Para ello se ponen ambas en una matriz y se identifica, para cada cruce, si la
estrategia de TI contribuye o no la estrategia de negocio dada. Con toda esta infor-
mación previa y con el conocimiento preciso del propio negocio y de cómo TI se
alinea con él, se aborda la selección de los objetivos de TI (Etapa IV).
A partir de este punto, para cada objetivo de TI se van identificando los indicado-
res de objetivos (KGI). Para cada indicador de objetivos se identifican los indica-
dores de rendimiento (KPI) que le apalancarán (Etapa V). En esta última etapa se
entra en un proceso iterativo en el que se relacionan en una tabla todos los indica-
dores posibles (coctelera de indicadores) seleccionados de diversas fuentes (las
métricas actuales, las deducidas por un ejercicio intuitivo, las que propone ITIL,
las que propone COBIT, etc.). Con todas estas métricas clasificadas, se estructuran
los tres niveles (KGI-TI, KGI-Proceso y KPI), o los establecidos por la arquitec-
tura de métricas que hayamos creado, y se realiza una selección intuitiva de las que
más contribuyen a los objetivos concretos de TI.
ETAPA I ETAPA II ETAPA II ETAPA IV ETAPA IV

Estrategia negocio Estrategia TI Alineación Objetivos TI Selección de
TI – Negocio las métricas
Objetivos de negocio (ejemplo) KGI de TI – Indicadores estratégicos
• COBIT–1. Expandir el porcentaje de mercado. • Disponibilidad de los servicios TI.

• COBIT–4. Optimizar el uso de recursos. • Coste TI por usuario.
• Madurez en la gestión de TI.
• COBIT–6. Mejorar la orientación y el servicio al cliente.
• Time-to-market medio de cambios.
• COBIT–9. Agilidad para responder a los requisitos cambiantes.
• Porcentaje de cambios en plazo.
• COBIT–18. Innovación del producto/negocio. • Satisfacción de los clientes y usuarios con TI.
• COBIT–20. Adquirir y mantener personal capacitado y motivado.
KGI de proceso – Indicadores tácticos

Objetivos de TI (ejemplo)
• Porcentaje de incidentes resueltos en plazo.
• COBIT–3. Asegurar la satisfacción de los usuarios finales con
• Incidentes resueltos en primera línea.
los servicios y niveles de servicio ofrecidos.
• Número de soluciones temporales activas.
• COBIT–5. Crear agilidad en TI.
• Porcentaje de CI con actualización automatizada.
• COBIT–8. Adquirir y mantener infraestructuras de TI integradas • Porcentaje de objetivos de SLA incumplidos.
y estandarizadas.
• Costes de provisión por servicio, etc.
• COBIT–15. Optimizar las infraestructuras, recursos y capacida-
des de TI.
• COBIT–21. Asegurar que los servicios e infraestructuras de TI KPI – Indicadores operativos
pueden resistir y recuperarse. • Número total de incidentes.
• COBIT–24. Mejorar la relación costes-eficiencia en las TI y su • Número de problemas abiertos.
contribución a los beneficios del negocio. • Número reuniones con clientes al mes.
• COBIT–25. Entregar los proyectos en tiempo y presupuesto • Porcentaje de objetivos de SLA en riesgo.
cumpliendo con los estándares de calidad. • Número medio de accesos per cápita a la CMDB.
NUEVO–Alcanzar una excelencia en procesos TI. • Número de cambios.
NUEVO–Mejorar productividad y satisfacción del empleado. • Porcentaje de cambios correctivos, etc.
Figura 6.2.12. Ejemplo de aplicación de la metodología para la obtención

de una arquitectura de métricas
En la figura 6.2.12 se muestra un ejemplo de los principales resultados de las Eta-

pas I, IV y V del proceso de definición de una arquitectura de métricas. Como
ejemplo, se han seleccionado los objetivos de negocio y de TI entre los objetivos
propuestos por COBIT, mientras que el resto de los indicadores de esta arquitec-
tura de métricas ejemplo se han seleccionado a partir de los indicadores proporcio-
nados al final de cada proceso en este libro.
Como resultado de este ejercicio se obtiene una arquitectura o mapa de indicadores de
TI que cubre todos los niveles de necesidad: cuadro de mando global de TI, cuadros
de mando de cada área de TI (de desarrollo, del producción de sistemas o del centro de
datos, del puesto de trabajo o microinformática, etc.), los indicadores de objetivos
de los procesos y los indicadores de rendimiento de cada uno de los procesos. En la
figura 6.2.13 se muestra el contenido del documento de una arquitectura de métricas.
Como parte de la arquitectura de métricas se debe definir de forma detallada cada
indicador, que servirá como base para su obtención y cálculo. La ficha contiene el
nombre del indicador, el código asignado al indicador, la versión del indicador
Estructura de una arquitectura de métricas
3 Alcance de la arquitectura.
3 Antecedentes en la organización.
3 Estrategia de la empresa. Objetivos de negocio
identificados.
3 Estrategia de TI. Objetivos de TI identificadas.
3 Alineación de TI con el negocio. Matriz cruce
objetivos negocio frente a TI.
3 Estructuración en capas de la arquitectura.
3 Métricas de objetivos de TI (KGI-TI).
3 Métricas de objetivos del área del centro de datos o
sistemas (KGI-CPD).
3 Métricas de objetivos del puesto de trabajo (KGI-PT).
3 Métricas globales de desarrollo (KGI-DES).
3 Fichas detalladas de los indicadores.
3 Etc.
Figura 6.2.13. Índice ejemplo de una arquitectura de métricas

(pues su definición y cálculo puede variar en el tiempo), proceso al que pertenece,

los valores máximos y mínimos esperados, la tendencia del indicador (es decir, si
debe ir al alza o a la baja), su valor de referencia, etc. En la figura 6.2.14 se muestra
la ficha típica para la definición de un indicador.
Ficha de definición de indicadores
Nombre indicador
Código Proceso Valor máx.
Versión Periodicidad Valor mín.
Categoría Ind/KPI/KGI Perspectiva (Norton y Kaplan) Valor mín. (Alza-Baja)
Descripción del indicador
Especificación
Justificación
Audiencia Responsable
Restricciones Padres (KPIs o KGIs a los que contribuye)
Fuentes de información Hijos (KPIs o KGIs que lo soportan)
Unidad de medida Dominio Valor objetivo Valor de riesgo
Fórmula
Figura 6.2.14. Ejemplo de ficha para la definición de un indicador
La base de datos de indicadores y mediciones

Si la arquitectura de métricas pone orden en la definición de los indicadores a utili-
zar, se pone de manifiesto que es necesario organizar también todas las mediciones
realizadas. Para ello, se propone centralizar en una base de datos tanto la definición
de los indicadores como el conjunto de mediciones que se realizan de cada uno de
ellos ya que, el volumen de estas mediciones, puede resultar muy elevado. En este
libro, al repositorio de mediciones se le ha denominado “histórico de mediciones”,
para resaltar el hecho de su utilidad para el análisis de tendencias y de la necesidad

de conservar mediciones pasadas.
Alojar las fichas que definen los indicadores en una estructura de base de datos,
permitirá incorporar fácilmente cualquier cambio en las fichas. Dado el alto volu-
men de indicadores gestionado en una organización madura, si las fichas alojan en
un archivo PowerPoint o Excel, incorporar un cambio en una ficha será una autén-
tica tortura de edición.
Así, la base de datos de indicadores y mediciones está formada por dos unidades
lógicas diferenciadas y relacionadas:
• La definición de indicadores, que aloja las fichas que definen cada uno de los
indicadores de la arquitectura de métricas.
• El histórico de mediciones, que almacena todas las mediciones en su detalle,
necesarias para los cálculos de los valores de los indicadores y para los análi-
sis de tendencias que se necesiten.
Una aproximación al diseño de la base de datos de indicadores y mediciones se

muestra en la figura 6.2.15.
Diseño de la base de datos de indicadores y mediciones
Ficha de definición de indicadores Histórico de mediciones

• Código indicador. • Responsable. • Código indicador.
• Nombre indicador. • Padres. • Versión indicador.
• Versión. • Hijos. • Código del elemento de
• Categoría. • Audiencia. configuración medido.
• Proceso. • Restricciones. • Marca de tiempo: fecha-
• Periodicidad. • Fuentes de hora-minuto-segundo.
• Perspectiva. información. • Valor medido.
• Valor máximo. • Unidad de medida. • Etc.
• Valor mínimo. • Dominio.
• Tendencia. • Valor objetivo.
• Descripción. • Valor de riesgo.
• Especificación. • Fórmula.
• Justificación. • Comentarios, etc.
Figura 6.2.15. Campos de la base de datos de indicadores y mediciones

Los informes en TI
Una vez definida la arquitectura de métricas e implementada la captura automati-

zada de los indicadores, se empezará a nutrir la base de datos de indicadores y
mediciones. En un lapso corto de tiempo, se podrán analizar las tendencias y el histó-
rico de mediciones comenzará a “engordar”, para aportar toda su valía cuando
alcance la madurez al pasar un año.
Una vez definidos y capturados los indicadores, la generación de los informes es
una tarea sencilla, pero requiere de capacidad de análisis, foco en la calidad de los
datos y una buena dosis de conocimientos estadísticos.
Después de su definición teórica llega la vida real. Un indicador se calcula en base a
múltiples mediciones de los elementos de configuración involucrados. Por ejem-
plo, el cálculo de la disponibilidad, el indicador estrella y concepto sencillo de
entender por el negocio, se suele realizar en base a mediciones en intervalos (entre
1 y 5 minutos). Si la disponibilidad es de un elemento de infraestructura, las medi-
ciones las facilitará la herramienta de monitorización local, si la disponibilidad es
de un servicio, se medirá mediante un agente de navegación desde un puesto
cliente. Además, habrá que recoger la disponibilidad en la franja horaria de cada
servicio (no es lo mismo que un surtidor de gasolina esté inoperativo de madru-
gada a que lo esté en plena actividad laboral), identificar las paradas planificadas,
calcular si es posible el impacto en el negocio de la no disponibilidad, y recoger, si
es factible, las causas de la indisponibilidad, etc. Así, el indicador ya medido y tra-
tado queda listo para ser incorporado en los diversos informes para su análisis y
utilización por parte del solicitante o destinatario del informe. Debemos recordar
que todas estas actividades las realizará el proceso de gestión de la disponibilidad,
siguiendo las pautas y tutela del proceso de generación de informes.
Dependiendo de la necesidad de la información a cubrir, los valores de un indica-
dor se presentan en un informe de diversas maneras:
• El valor en el período. Representado en forma numérica el valor en el perí-
odo de medición, como porcentaje, plazo de tiempo, cantidad, etc.
• Un semáforo, indicando si se han cumplido o no los niveles de servicio espe-
rados en el intervalo de medición. Representado, generalmente y por senci-
llez, en tres colores: rojo, naranja/amarillo y verde.
• Su evolución histórica a lo largo de días o meses. En este tipo de gráfico se
muestra la tendencia del indicador. En la representación gráfica también
deberían aparecer los umbrales mínimo y máximo del indicador junto con
su evolución en el tiempo.
• Comparativas históricas entre indicadores en un mismo gráfico, para aque-

llos en los que haya una relación entre ellos. Por ejemplo, la disponibilidad
diaria con el número de cambios o la disponibilidad horaria con la carga de
transacciones.
• Visión de varios indicadores en un período, representados en una tabla de
valores, en un gráfico de Kiviat en forma de estrella, etc.
• Tendencia del indicador. De forma general, en ITIL se considera más conve-
niente representar los indicadores no con el valor propio del período, sino
como una tendencia de crecimiento o decrecimiento en el período actual en
relación a períodos anteriores a efectos de tomar decisiones de actuación
(corrección y mejora). Por ejemplo, tradicionalmente se mide el “volumen
de cambios rechazados”. En el caso de ITIL se recomienda medir también el
“porcentaje de disminución de los cambios rechazados”. Esta forma de
expresar los indicadores permite conocer la tendencia de mejora, pero puede
resultar poco intuitiva y farragosa si sólo se observan los indicadores de ten-
dencia, por lo que en este libro se ha optado por mostrar directamente el
valor del indicador en el período de medición.
En relación a los informes, la Norma ISO/IEC 20000-1 requiere que los mismos
estén identificados y que se verifique el cumplimiento de los requisitos y necesi-
dades del negocio. También establece los conceptos mínimos a cubrir en los
informes.
UNE-ISO/IEC 20000-1
Se debe describir claramente cada informe de servicio, incluyendo su identificador,

el propósito, la audiencia y los detalles del origen de los datos.
Los informes de servicio se deben generar para verificar si se cumplen los requisitos
y necesidades de los usuarios. Los informes de servicio deben incluir:
a) el rendimiento y comportamiento frente a los objetivos de nivel de servicio;
b) las no conformidades y problemas relacionados, por ejemplo con los SLA o
agujeros de seguridad;
c) las características de la carga de trabajo, por ejemplo volumen o utilización
de recursos;
d) los informes de los resultados de los principales eventos, por ejemplo los prin-
cipales incidentes y cambios;
e) la información sobre tendencias;

f) el análisis de satisfacción.
Las decisiones de gestión y las acciones correctivas deben tener en cuenta los aspectos
destacados en los informes de servicio y deben comunicarse a las partes afectadas.
En la Norma ISO/IEC 20000-2 se desarrolla algo más el propósito de los informes

del servicio, poniendo énfasis en su generación a tiempo, en su claridad y en la fia-
bilidad de los datos contenidos. Además, recomienda generar informes de varios
tipos: reactivos, proactivos y de planificación de actividades.
UNE-ISO/IEC 20000-2
Propósito de los informes del servicio Se deberían generar distintos tipos de

y verificación de su calidad informes:
Los informes de servicio se deberían a) informes reactivos, que muestran
generar a tiempo, y ser claros, fiables y lo que ha ocurrido;
concisos.
b) informes proactivos, que avisen
Se deberían adecuar a las necesidades por adelantado de eventos signifi-
de quien lo recibe y ser suficientemente cativos con objeto de permitir que
precisos para poder ser utilizados como se puedan realizar acciones pre-
herramienta de apoyo en la toma de ventivas (por ejemplo, informes
decisiones. sobre inminentes rupturas de los
SLAs);
La presentación debería ayudar a com-
prender los informes de forma que sean c) distribución previa de informes
fácilmente asimilables, por ejemplo que muestren las actividades pla-
usando gráficos. nificadas.
También en la Norma ISO/IEC 20000-2 se vuelve a tratar el alcance que deberían

cubrir los informes del servicio.
UNE-ISO/IEC 20000-2
Informes de servicio
a) comportamiento frente a objetivos
El proveedor del servicio debería generar de nivel de servicio, por ejemplo
informes para los clientes y para la direc- informes de caídas del servicio,
ción, que cubran los siguientes aspectos: logros;
b) no conformidades frente a nor- e) información de tendencias por

mas; periodos (por ejemplo diaria,
semanal, mensual);
c) características de la carga de tra-
bajo y volumen de la información, f) informes que incluyan informa-
por ejemplo incidentes, proble- ción de cada proceso, por ejem-
mas, cambios y tareas, clasifica- plo número de incidentes y de
ción, ubicación, clientes, tenden- preguntas más frecuentes, com-
cias estacionales, combinación de ponentes de la infraestructura
prioridades, número de solicitu- poco fiables, tareas que consu-
des de ayuda; men gran número de recursos
económicos, técnicos o humanos;
d) informes de resultados después
de eventos de alto nivel, por g) informes para destacar cargas de
ejemplo cambios y entregas; trabajo futuras o planificadas.
Aunque en el apartado 6.2 de estas normas se refiere al término de “informes del

servicio”, en realidad, para cubrir sus requisitos y recomendaciones, se requiere desa-
rrollar todo tipo de informes, tal y como se trata en este libro.
Las organizaciones con una excelencia en la gestión de TI, suelen generar una
buena cantidad de informes, necesarios tanto para la gestión como para la toma de
decisiones. Los principales informes son (nótese que en este libro se han incluido
como informes el panel de control y los informes instantáneos, generados dinámi-
camente, ya que ambos son también una forma de mostrar los indicadores e infor-
mación sobre TI y que sirven para la toma de decisiones):
• El panel de control de TI. Información continua proporcionada por la moni-
torización en tiempo real y mostrada en las consolas de monitorización.
• Los informes instantáneos generados online y accesibles vía web. Correspon-
den a consultas en vivo sobre los indicadores. El ejemplo más significativo
de estos informes lo proporcionan las utilidades de navegación sobre los ser-
vicios, que mezclan información de la CMDB y de la monitorización en
tiempo real.
• Informes del servicio. Son los informes de gestión de TI por excelencia.
Aglutinan toda la información necesaria para gestionar las TI, en sus visio-
nes diarias, semanales, mensuales, trimestrales y anuales.
• Los cuadros de mando de TI. Que muestran, con la periodicidad que se haya
acordado o sea requerida, el estado de TI en base a una selección de los prin-
cipales indicadores. En organizaciones grandes hay un cuadro de mando
general de TI y otros cuadros de mando específicos para cada área: del puesto
de trabajo (microinformática y red), del centro de datos (o explotación de sis-

temas) y de desarrollo de aplicaciones.
• Además hay planes, documentos específicos que se genera en cada proceso
anualmente y que se actualizan mensual o trimestralmente (a lo largo de este
libro se describe el contenido de ellos), aunque el objeto de este proceso no
son esos planes y documentos, pero sí la generación de los informes para el
seguimiento de sus objetivos. De esta forma, se tiene una visión general de
toda la información generada para la gestión de TI. Entre ellos destacan:
– El plan financiero de TI y sus informes periódicos.
– El plan de capacidad y sus informes.
– El plan de disponibilidad y sus informes.
– El plan de continuidad de TI y los informes de las pruebas.
– El plan de mejora unificado de los procesos y de los servicios, y los infor-
mes derivados de seguimiento.
– El plan de proyectos o el informe de iniciativas estratégicas de transforma-
ción y los informes para su seguimiento.
– La lista de cambios planificados (FSC) y sus actualizaciones.
– El informe sobre los problemas.
– Otros informes específicos de cada proceso: seguridad, etc.
En la figura 6.2.16 se muestra la relación de los principales informes en TI y su

contribución a los aspectos reactivos, proactivos y de planificación; tal y como
recomienda la Norma ISO/IEC 20000-2. Además, se clasifican según el ámbito al
que vayan destinados: estratégico, táctico u operativo.
Según la necesidad a cubrir, los informes se suelen generar con una periodicidad
diversa: anual (visión estática, definición objetivos), trimestral (grado de avance de
los grandes objetivos anuales), mensual (niveles de servicio, consecución objetivos
mensuales), semanal (relativos a volumetrías y niveles de servicio) e incluso diario
(eventos y actividades ocurridas en el día). En la figura 6.2.17 se muestra una apro-
ximación a la periodicidad en la generación de los informes.
Como se ha señalado en la figura 6.2.17, los informes del servicio se pueden gene-
rar con diversa periodicidad y su contenido varía según el período. Así, se podrán
generar de forma diaria, semanal, mensual y anual:
Informe del servicio diario. Proporciona cierta información de la actividad ocurrida
en el día, como, por ejemplo, los incidentes graves, las peticiones de los usuarios más
Figura 6.2.16. Clasificación de los informes más relevantes utilizados en TI
Figura 6.2.17. Periodicidad de los diversos informes en TI

destacadas, los cambios más relevantes o los volúmenes de actividad del día. Estos
informes son descriptivos de lo acontecido en el día y no suelen contener gráficos de
indicadores.
Informe del servicio semanal. Proporciona información de lo ocurrido en la

semana y permite el control y planificación semanal de la actividad. Contiene una
parte liviana de indicadores. Casi toda la información que contienen es descriptiva
de lo ocurrido en la semana: incidentes, cambios y actividad de TI. Suele incorpo-
rar también los valores de disponibilidad de la semana y la acumulada en el tramo
de mes transcurrido. La disponibilidad se presenta sobre los servicios críticos, con
el fin de tener un control más detallado semana a semana de esta métrica.
En la figura 6.2.18 se muestra un ejemplo de la estructura de estos informes del
servicio.
Estructura de una arquitectura de métricas
Informe del servicio diario:

• Fecha, código de informe y responsable.
• Descripción de incidentes graves del día.
• Peticiones relevantes de los usuarios (VIP).
• Resultados de los cambios ejecutados en el día.
Informe del servicio semanal:

• Fecha, código de informe y responsable.
• Descripción de incidentes graves semana.
• Peticiones relevantes de los usuarios (VIP).
• Resultados de los cambios ejecutados en el día.
• Actividades realizadas en la semana.
• Actividades previstas para la semana próxima.
• Disponibilidad de los servicios críticos acumulada en el mes.
• Disponibilidad total acumulada en el mes.
Figura 6.2.18. Índice ejemplo de los informes diario y semanal del servicio
Informe del servicio mensual. Es el informe más relevante para la gestión de TI.
Contiene toda la información necesaria para conocer y controlar el devenir de la
actividad. Suele constar de un resumen general y un resumen de cada parte rele-
vante de TI que interese seguir mensualmente:
• Resumen ejecutivo del mes.
• Informe sobre la disponibilidad.
• Informe sobre los incidentes y el análisis causal asociado.
• Análisis de las peticiones de usuario realizadas.
• Informe estadístico y descriptivo de los cambios.
• Informe de los proyectos y las iniciativas de transformación de TI.
• Análisis y volumetrías de transacciones.
• Resumen del estado presupuestario en el mes.
• Variación de la planta, descripción de las capacidades de provisión, en lo rela-
tivo a la planta y en las capacidades de trabajo (sourcing).
• Información resumen sobre el resultado del resto de procesos de gestión
TI, etc.
En la figura 6.2.19 se muestra un ejemplo del contenido del informe mensual

sobre el servicio de TI desde la perspectiva de la prestación del servicio. Hay que
tener en cuenta que para el área de desarrollo de aplicaciones la información a
tratar para su gestión sería otra muy distinta y origina otro modelo de informe.
El informe mensual comienza con una parte destinada al resumen ejecutivo, en la
que se reflejan los indicadores más importantes para la gestión de TI, como por
ejemplo, la disponibilidad y tiempo de respuesta de los servicios; los tiempos de
resolución y volumen de actividad de incidentes, peticiones de usuario y cam-
bios; información sobre los proyectos del ámbito de infraestructuras; resumen
del grado de cumplimiento presupuestario y la desviación sobre las previsiones;
un conjunto de indicadores que aporten una visión sobre la calidad de los servi-
cios y la eficiencia del trabajo; también es recomendable presentar una visión del
estado de la planta y la capacidad de trabajo disponible (medida mediante el indi-
cador de personas trabajando a tiempo completo equivalentes o FTE (Full Time
Equivalent), que traduce a jornadas equivalentes de 8 horas el volumen de perso-
nal interno, de personal externo y de los servicios contratados); para cerrar el
resumen ejecutivo con un campo descriptivo que permita destacar los aspectos
más relevantes del mes.
Figura 6.2.19. Diseño ejemplo de un informe mensual sobre el servicio:

apartado específico del resumen ejecutivo
Dentro del informe mensual del servicio (en la figura 6.2.20 se muestra un ejem-
plo), uno de los apartados más relevantes es el relativo al análisis de la disponibili-
dad de los servicios. En el ejemplo se muestran las cifras alcanzadas por cada uno
de los servicios en el mes, junto a una gráfica de la evolución mensual del indica-
dor, representando también la disponibilidad de los servicios críticos. Como en
todos los informes, se deben comentar los aspectos más destacados relativos al
asunto que se esté tratando (disponibilidad, etc.) que hubieran ocurrido en el mes,
así como las acciones de mejora emprendidas.
Informe del servicio anual. Muestra un resumen consolidado de la actividad y las

cifras del año. Suele mantener la estructura de un informe mensual conteniendo
valores referentes al año.
Figura 6.2.20. Diseño ejemplo de un informe mensual sobre el servicio:

apartado de disponibilidad de los servicios
Métricas propias del proceso de gestión de informes

El propio proceso de generación de informes del servicio tiene sus métricas especí-
ficas que informan sobre su funcionamiento.
Como se indica en el objetivo del proceso, “los informes de servicio se deberán
generar a tiempo, y ser claros, fiables y concisos”. Las métricas del proceso moni-
torizarán el cumplimiento de estos objetivos, se medirá la generación y entrega en
plazo y serán fiables. Algunas métricas relevantes del proceso pueden ser:
• Porcentaje de incumplimientos de SLA debido a que los informes no se han
entregado en el plazo o con la calidad acordada.
• El porcentaje de los informes entregados en plazo.
• La calidad del dato en los informes, medida como el porcentaje de errores

medio por informe.
• La tasa de indicadores definidos en la arquitectura de métricas que de verdad
se están midiendo.
• El grado de automatización en la obtención de las mediciones de los indica-
dores, que permitirá conocer cuantos indicadores se obtienen de forma com-
pletamente automática sin requerir el tratamiento humano.
• La cantidad de indicadores medidos.
• La cantidad de informes generados.
• El coste medio de toda la actividad de medición dividido entre el número de
indicadores, nos dará una idea del esfuerzo que se está realizando en la
obtención de mediciones.
• El coste medio por informe generado.
En el gráfico de la figura 6.2.21 se muestra un resumen de los indicadores más rele-

vantes para este proceso.
Figura 6.2.21. Métricas principales para el proceso

Roles participantes en generación de informes de

servicio
Dado que la generación de informes es una actividad considerada no grata por las
áreas técnicas, tiene todo su sentido plantearla como una actividad con dedicación
específica centralizada común para todo TI, que desde un punto central se recopile
toda la información y se generen los informes, o por lo menos los más generalistas
(informes del servicio o cuadros de mando), dejando los informes especializados
(informe financiero de TI, informe de capacidad, etc.) a cada proceso.
Aunque la generación de informes se centraliza en un proceso, se necesita la parti-
cipación de los otros procesos y áreas de TI de cara a incorporar las métricas y
medidas, y la interpretación y análisis de la información presentada.
• El gestor del proceso de generación de informes (gestor del proceso o process
manager). Es responsable de la operación diaria del proceso de generación de
informes. Vela tanto por la definición de la arquitectura de métricas como por
la ejecución de los informes en plazo y con calidad. Además, no sólo debe ges-
tionar la generación de los informes, sino que también debe conocer en detalle
y “de memoria” las principales cifras de su organización y los ratios equivalen-
tes del mercado, de tal forma que pueda asesorar a la dirección de TI y a los
clientes sobre los indicadores más adecuados, sus valores actuales y los de refe-
rencia. Se relaciona con el resto de responsables de proceso y de las áreas para
conseguir que los informes contengan información útil para ellos. También
se encarga de que los informes se utilicen en la gestión y gobierno de TI.
• En lo relativo a la etapa de definición de la arquitectura de métricas, los roles
adicionales al gestor del proceso son:
– El consultor de métricas que define la arquitectura de métricas, alineando
los indicadores con los objetivos de TI y del negocio. Además debe definir
en detalle las fichas de los indicadores.
– El técnico encargado de la definición y creación de la base de datos de
indicadores y mediciones.
– El técnico de implantación de las herramientas de monitorización en lo
relativo a la captura automatizada de los valores y su carga en la base de
datos de indicadores y mediciones.
• En lo relativo a la generación de los informes, los roles adicionales al gestor

del proceso son:
– El responsable de generación de los informes (incluidos los cuadros de

mando), que vela por la calidad de la información y para que los informes
se generen a tiempo. Conoce en detalle todos los indicadores y ratios de
TI. Se encarga de que los informes sean conocidos y utilizables por las
áreas destinatarias.
– El técnico de implantación de las herramientas de cuadro de mando, de
acceso web al repositorio de informes, de generación de informes online y
de la navegación gráfica sobre los componentes de un servicio.
– En este ámbito, también se suelen incluir perfiles estadísticos para el ajuste
y análisis de tendencias a efectos de garantizar la exactitud del dato y la
usabilidad del mismo, no siendo su cometido el análisis de la información,
ya que esto corresponde a los destinatarios y solicitantes (generalmente el
resto de procesos de TI).
• Los administradores o el personal de soporte al proceso. Personal que con-

tribuye en organizar la actividad, preparar los informes, etc.

cumplan los niveles pactados. Aporta las necesidades de información, indica-
dores e informes necesarios para la gestión del servicio. Revisa y valida los
valores e información contenidos en los informes.
• El responsable de la gestión de nivel de servicio, que especifica los niveles de
servicio que se van a medir y contemplar en los informes. Además, revisa y
contrasta los valores de su competencia incluidos en los informes.
• El responsable de las relaciones con el negocio, que participa en la definición
de los informes que necesita entregar a sus clientes.
• Los responsables del resto de los procesos, pues especifican los indicadores y
necesidades de informes, o bien, los generan ellos mismos (por ejemplo, el
informe de capacidad o el informe financiero).
(process owner), define el proceso y vela por el cumplimiento y actividades del
proceso, y se encarga de la mejora continua del mismo.
Los roles de mayor relevancia que participan en la generación de informes de servi-

cios se representan en la figura 6.2.22.
Roles del proceso
Responsable de la
Gestor del
proceso de informes
Consultor
de métricas
Gestores de otros
procesos y áreas TI
SGSTI
Responsable de generación
de los informes
Especialistas en el Administrador y
Propietario del
modelo (SGSTI) diseño del servicio soporte del proceso
Figura 6.2.22. Roles del proceso de generación de informes del servicio
Resumen
Los indicadores e informes son una necesidad innegable en una gestión con cali-
dad de TI, pero su generación ha sido siempre una de las asignaturas pendientes de
las organizaciones, muy centradas en la tecnología y el día a día, y poco en el
gobierno y la gestión.
El proceso de generación de informes de servicio centraliza las arduas activida-
des de recopilación de indicadores e información, para generar unos informes
con la calidad del dato contrastada, en los plazos convenidos y con la máxima
eficiencia.
Aunque en las Normas ISO/IEC 20000 los requisitos para el proceso son más
reducidos, en este apartado se han desarrollado en toda su amplitud, con el fin de
llevar a las organizaciones de TI a la excelencia.
La generación de informes pasa por la definición de una política de informes, que
marque las directrices a cumplir en cuanto al suministro de información.
Un segundo paso recomendado, es la creación de una arquitectura de métricas, que
defina y estructure los indicadores a medir, poniendo orden y posibilitando la con-
tinuidad en las mediciones.
Las organizaciones situadas en las mejores prácticas, disponen de una base de datos
centralizada (o bien federada) en la que incorporan las definiciones de los indica-
dores y todos los históricos de las mediciones.
Los principales informes de TI van más allá de representar únicamente cifras sobre
cumplimiento de los niveles de servicio. El alcance de los informes abarca todo tipo
de información analítica y descriptiva. También se considera dentro del alcance a la
información mostrada en vivo. Así, los principales informes son:
• Informes del servicio: diarios, semanales, mensuales y anuales.
• Cuadros de mando de TI.
• Informe financiero de TI.
• Informe de capacidad.
• Informe de disponibilidad.
• Informe de continuidad de TI.
• Informe de mejora global: SIP + procesos.
• Informe de cada proceso.
• Lista de cambios planificados (FSC).
• Informes de proyectos e iniciativas estratégicas.
• Informe de problemas.
También se consideran dentro del alcance del proceso los paneles de control, con
gráficas que muestran en tiempo real el estado de los servicios y las infraestructu-
ras, así como, los informes generados de forma instantánea (por ejemplo, vía web).
Para poder tratar el ingente volumen de datos, es necesaria la máxima automatiza-
ción, desde la captura de las mediciones mediante las herramientas de monitoriza-
ción, pasando por la carga a la base de datos referida anteriormente, hasta llegar a
la generación instantánea (online) de los informes.
La fiabilidad y la calidad de los datos son esenciales para que los informes sean de
utilidad.
Muchos de los informes contienen también tendencias, descripciones y análisis de
las actividades y sucesos ocurridos en el período.
Beneficios
Los principales beneficios aportados por el proceso de generación de informes son:
• La centralización de la generación de informes en un proceso facilita la espe-
cialización, y permite al resto de procesos y áreas de TI centrarse en sus
cometidos.
• Los informes y las métricas se diseñan y gestionan de forma común.
• Los informes se planifican con una visión común de las necesidades de TI y
de los clientes, lo que permite más claridad y concisión. Además se ofrece
una visión más homogénea sobre toda la actividad de TI.
• Cada área recibe los informes que necesita y con la periodicidad acordada.
• Es más fácil garantizar que la información es fiable. Existe un responsable de
cada dato y de cada informe.
• El diseño común por especialistas facilita que la información sea más clara y
entendible por los destinatarios.
• Se centralizan en un punto todos los indicadores y todas sus mediciones.
Con lo cual, cualquier cambio o nuevo informe será más fácil de implemen-
tar, al tener la información histórica registrada.
• La centralización facilita la creación una plataforma común para la genera-
ción y difusión de los informes. Además, la dedicación específica a esta acti-
vidad aumenta la productividad en la generación de informes.
• La organización de TI conoce los resultados de su trabajo, con claridad y a
tiempo. Por tanto, mejora su motivación.
• La comunicación e información clara y a tiempo permite mejorar la satisfac-
ción de los clientes.
• ¿Cuáles son los 10 indicadores principales que se utilizan en su orga-
nización¿
• Enumere los informes generados en un año en el ámbito de TI en su
organización
• ¿Qué aporta los marcos de ITIL y COBIT a los indicadores e informes?
1
99,99%

6.3. Gestión de la continuidad y disponibilidad del servicio 279
6.3. Gestión de la continuidad y disponibilidad

del servicio
Figura 6.3.1. Esquema general del proceso de la gestión de

la disponibilidad y de la continuidad
Bienvenido al “astro rey” de la informática, la piedra angular sobre la que gravita la

actividad de TI: ¡la disponibilidad! Es absolutamente importante y además está
continuamente en boca de todos, tanto en la dirección de TI como en el negocio.
Situación que ya de partida es un mal augurio, tanta preocupación de los clientes
por ella viene a resaltar que los servicios prestados fallan y fallan, escenario genera-
lizado en una industria que no acaba de alcanzar la madurez necesaria (véase la
figura 6.3.1).
Los servicios en TI deberían estar operativos cuando los necesite el negocio y de la
manera que los necesite. Pero la realidad en TI es bien distinta, y se está lejos de ofre-
cer unos servicios tan omnipresentes que sus fallos y caídas se pierdan en la memoria
de los tiempos. Hasta que se alcance ese paraíso, la disponibilidad seguirá saltando
más allá de los ámbitos técnicos, para continuar siendo el centro de las preocupacio-
nes de la dirección de la empresa cuando piensa en los sistemas de información.
Emulando la pirámide de necesidades del ser humano definida por Maslow, la dispo-
nibilidad de los servicios se situaría en la base, en las “necesidades físicas” primarias
de TI, sin la cual no se puede sobrevivir. Para el negocio, la disponibilidad de los

servicios es como el aire que respiramos. No es extraño, ya que una no disponibili-
dad en algún servicio implica que alguien en la empresa no puede hacer su trabajo,
que se quede parado o incluso que se estén perdiendo clientes.
De forma paralela al concepto de la disponibilidad cotidiana de los servicios, apa-
rece la necesidad de garantizar que los servicios se puedan seguir utilizando des-
pués de un evento catastrófico. Así, resurge el antiguo concepto de continuidad de
los servicios de TI, tan ignorado o postergado en muchas organizaciones de TI, y
hasta tal punto denostado, que en muchos sectores críticos (por ejemplo, el finan-
ciero) ha sido necesaria la legislación gubernamental para garantizar a la sociedad
la supervivencia de sus servicios y de la información asociada.
Las mejores prácticas existentes, conscientes de la realidad imperfecta de esta indus-
tria, no aspiran a la perfección. Centran el foco en que los servicios se diseñen para
cumplir lo pactado con los clientes en los acuerdos de nivel de servicio (SLA). Así,
todas las medidas para garantizar la disponibilidad y continuidad deben estar aline-
adas con estos SLA.
Pero además, TI tiene la obligación de compararse con el segmento de mercado al
que se equipara, con el que compite la empresa, para garantizar que los niveles de
servicio que ofrece y acuerda con su negocio sean parejos o superiores a los de la
competencia.
De forma simplificada, se puede decir que la disponibilidad tiene como objetivo
garantizar que los servicios requeridos por el negocio son prestados cuándo y cómo
se necesitan bajo condiciones normales, mientras que la continuidad se encarga de
garantizar la persistencia de los servicios ante condiciones extraordinarias (fuego,
inundaciones, terrorismo, sabotajes, etc.).
Sintetizando estos conceptos en una sola palabra, se puede decir que la gestión de
la disponibilidad es sinónimo de fiabilidad, mientras que la gestión de la continui-
dad es sinónimo de supervivencia.
En relación a la causa que origina la perturbación la disponibilidad y la continui-
dad son fácilmente separables, pero ambas tienen muchas disciplinas comunes: la
identificación de las funciones vitales de negocio, el análisis de riesgos, el trabajo en
base a planes, etc. Por eso, las Normas ISO/IEC 20000 las unifican en un sólo pro-
ceso, en cambio, en ITIL son tratados como dos procesos independientes (libro
Diseño del Servicio, proceso de gestión de la disponibilidad y proceso de gestión de
la continuidad de TI).
En este apartado se respeta la unificación de procesos realizada en ISO/IEC 20000,
pero se explican las buenas prácticas de forma diferenciada, identificando las disci-
plinas comunes y las formas de trabajo muy distintas en cada uno.
99,99%

En la figura 6.3.2 se muestra una visión introductoria al proceso de gestión de la

disponibilidad y continuidad del servicio de TI.
Proceso de gestión de la Qué aporta:

disponibilidad y continuidad • Un plan de disponibilidad orientado
a mejorar la disponibilidad general.
• Toma de conciencia sobre los
Definición: servicios críticos para el negocio.
Proceso responsable de ofrecer unos • Garantizar que se pueden satisfacer
niveles de disponibilidad adecuados las necesidades de disponibilidad
a las necesidades de los clientes y actuales y futuras.
unos niveles de funcionamiento
acordados tras una contingencia. • Conseguir reducir la frecuencia y
la duración de las incidentes que
quebranten la disponibilidad.
Objetivo: • Minimizar la interrupción de las

actividades de negocio.
Asegurar que los compromisos de
continuidad y disponibilidad acordados • Un plan de continuidad para prevenir,
con los clientes pueden cumplirse bajo detectar, preparar y mitigar los
todas las circunstancias. efectos de los desastres.
Figura 6.3.2. Introducción al proceso de gestión de la disponibilidad y continuidad
Según establecen las Normas ISO/IEC 20000, el objetivo de la disponibilidad y

continuidad es asegurar que los compromisos de continuidad y disponibilidad
acordados con los clientes pueden cumplirse bajo todas las circunstancias.
La disponibilidad se centra en:
• Desarrollar el plan de disponibilidad de TI, para cumplir con los requisitos
del cliente y alineado con el mercado.
• Reducir los tiempos de mantenimiento y no disponibilidad.
• Promover una actitud proactiva para reducir la frecuencia y duración de los
fallos informáticos.
La continuidad se articula en torno a:

• El desarrollo y actualización del plan de continuidad de TI, acorde con la
estrategia y el plan de continuidad del negocio.
• Minimizar la interrupción de las actividades de negocio tras un desastre.

• Reducir la vulnerabilidad mediante un eficaz análisis y gestión de riesgos.
Como se muestra en la figura 6.3.3, una arquitectura robusta, el conocimiento téc-

nico y la constancia son los principios básicos en los que fundamentar la gestión de
la disponibilidad y continuidad.
Figura 6.3.3. Principios básicos de la gestión de la disponibilidad y continuidad
La combinación adecuada de estos tres principios permite establecer y gestionar de

manera eficaz este proceso.
El factor principal de éxito de la disponibilidad y la continuidad es un diseño ade-
cuado de la tecnología en la que se basan los servicios. Así, resulta esencial la defi-
nición de unas directrices técnicas para la construcción de las aplicaciones y de una
arquitectura para las plataformas tecnológicas, con la redundancia y replicación en
remoto necesarias para garantizar los niveles de servicio comprometidos.
El conocimiento técnico permitirá realizar el diseño de las soluciones técnicas, pues
la disponibilidad y la continuidad son elementos que se conciben en el momento
en que se crea el servicio. Participa también en el análisis proactivo de riesgos y
forense de incidentes, para establecer las soluciones adecuadas. El componente téc-
nico es importante en este proceso.
Más allá del empuje inicial para definir e implantar los planes de disponibilidad y
de continuidad, es necesario mantener una constancia diaria para conseguir que se
99,99%

lleven a cabo las tareas definidas, muchas de ellas, con una visión a futuro que com-
pite con las prisas y sobrecarga que conlleva el día a día de los servicios.
Como es normal, las Normas ISO/IEC 20000 no definen una estructuración de las
actividades que se deben realizar. Por eso, en este apartado se detalla el proceso
tomando como base la estructura para la gestión de la continuidad de cuatro blo-
ques utilizada en ITIL v2:
• Inicio o implementación del proceso.
• Definición de los requerimientos y de la estrategia a seguir en el proceso.
• Implementación de las soluciones.
• Gestión operativa del proceso.
Sobre estos bloques se detallan las actividades que se deben realizar y se añade un
quinto con las actividades de mejora del proceso, típicas de estas normas.
En la figura 6.3.4 se muestran las diversas estructuras que se dan al proceso de ges-
tión de la disponibilidad en las versiones 2 y 3 de ITIL. Aunque las agrupaciones y
denominación de las actividades difieren, el concepto de fondo en el proceso es
siempre el mismo.
En ITIL v2 la disponibilidad se estructura En ITIL v3 la disponibilidad se agrupa

en dos áreas: planificar y supervisar en dos bloques: reactivas y proactivas
Disponibilidad en ITIL v2 Disponibilidad en ITIL v3
• Planificar: • Actividades reactivas:

– Determinar requisitos. – Monitorización, medición, análisis de informes,
– Diseñar para la disponibilidad. revisión del servicio y disponibilidad de los com-
– Diseñar para la recuperación. ponentes.
– Verificar la seguridad. – Investigación indisponibilidad de todos los servi-

cios y componentes, e impulsar soluciones.
– Planificar paradas.
– Obtener y mantener el plan de disponibilidad. • Actividades proactivas:
– Evaluación y gestión del riesgo.
• Supervisar:
– Planificación y diseño para servicios nuevos o
– Establecer métricas e informes. modificados.
– Monitorizar y analizar tendencias. – Implementar contramedidas justificadas en costes.
– Revisar la disponibilidad. – Revisión de todos los servicios, nuevos y modifi-
– Investigar la indisponibilidad. cados, prueba de la disponibilidad y mecanismos
– Mejorar la disponibilidad. de resistencia.
Figura 6.3.4. Diferentes aproximaciones a la disponibilidad en ITIL

Si bien la disponibilidad se trata bajo dos agrupaciones de actividades distintas en

las dos versiones de ITIL, en la gestión de la continuidad se ha seguido una misma
estructura de 4 bloques. Las actividades contempladas son similares, pero enuncia-
das de forma distinta, como se muestra en la figura 6.3.5. En las dos versiones de
ITIL no varía un ápice el objetivo y espíritu de estos procesos.
Continuidad en ITIL v2 Continuidad en ITIL v3
• Inicio: • Inicio:
– Definir política continuidad. – Fijar política continuidad.
– Ámbito de la continuidad. – Ámbito de la continuidad.
– Definición e inicio proyecto continuidad. – Inicio del proyecto continuidad.
• Requerimientos y estrategia: • Requerimientos y estrategia:
– Análisis impacto en el negocio. – Análisis impacto en el negocio.
– Evaluación del riesgo. – Evaluación de riesgos.
– Definición estrategia continuidad negocio. – Definición estrategia continuidad de TI.
• Implementación: • Implementación:
– Organización y planificación implementación. – Desarrollo planes continuidad de servicios TI.
– Desarrollo planes de recuperación. – Desarrollo planes TI, planes recuperación y
– Implementar medidas de reserva. procedimientos.
– Implementar medidas reducción del riesgo. – Planificación de la organización.
– Desarrollar los procedimientos. – Prueba de la estrategia.
– Pruebas iniciales. • Gestión operativa:
• Gestión operativa: – Educación, concienciación y formación.
– Educación y concienciación. – Revisión y auditoría.
– Revisión y auditoría. – Pruebas.
– Pruebas. – Gestión de cambios.
– Control de cambios. • Invocación
– Formación.
– Aseguramiento.
Figura 6.3.5. Estructura bastante similar de las actividades de continuidad

en las dos versiones de ITIL
La gestión de la disponibilidad y continuidad utilizan un entorno muy rico y

maduro de técnicas y componentes. Para el análisis de los riesgos se utilizan disci-
plinas compartidas con la seguridad, realizando la identificación de las funciones
que son vitales para el negocio y el análisis de impacto de las amenazas. También se
99,99%

aplican las metodologías de gestión de riesgos, se identifican los requisitos del

negocio y se establecen las directrices de diseño y arquitecturas. La implementa-
ción se articula en torno a planes que se revisan de forma periódica. Se realizan
pruebas, para garantizar su correcto funcionamiento. Los mecanismos principales
utilizados en este proceso para alcanzar sus objetivos, se muestran en la figura 6.3.6
agrupados en función de cada una de las etapas.
Figura 6.3.6. Elementos del proceso de gestión de la disponibilidad y de la continuidad
Los elementos principales que integran el proceso de gestión de la disponibilidad y

de la continuidad son:
Conceptos básicos. El proceso trata con los siguientes conceptos básicos:
• Continuidad. Capacidad de seguir prestando los servicios del negocio o de
TI después de un desastre.
• Disponibilidad. Período en que una función está plenamente utilizable por

los usuarios. Se distingue entre disponibilidad del componente (analizado
como elemento técnico aislado) y la disponibilidad del servicio (como un con-
junto de elementos de configuración que presta una funcionalidad al negocio).
• Fiabilidad. La fiabilidad de un servicio o componente se entiende como lo
fidedigno que es o lo libre que está de fallos (mide la frecuencia entre fallos).
• Mantenibilidad. Viene a representar facilidad con que puede ser reparado o
devuelto a su estado normal de funcionamiento a un componente de la
infraestructura. Normalmente realizado por personal interno.
• Serviciabilidad. Indicador del nivel y calidad del mantenimiento proporcio-
nado por terceros (mantenibilidad proporcionado por terceros).
• Seguridad. La confidencialidad, integridad y disponibilidad de los datos rela-
cionados con un servicio; se trata de un aspecto de disponibilidad general.
Análisis del árbol de fallos (FTA, Fault Tree Analysis). Método de análisis de los
sucesos ocurridos en un servicio para determinar la causa una interrupción de
los servicios de TI. Se representa una cadena de sucesos en un esquema en forma
de árbol booleano.
Análisis de impacto en el negocio (BIA, Business Impact Analysis). Análisis del
impacto que tendrían los riesgos en la actividad de la empresa u organización, si se
produjera la parada de una función de negocio. Permite identificar y ponderar cuá-
les son las funciones de negocio vitales que deberán protegerse mediante la dispo-
nibilidad, la continuidad y la seguridad. Este análisis es fundamental para el des-
arrollo de las actividades de estos procesos.
Análisis del impacto por el fallo de un componente (CFIA, Component Failure
Impact Analysis). Predecir y estimar el impacto sobre la disponibilidad del servicio
derivada de los fallos de los componentes incluidos en la infraestructura de TI y del
diseño del servicio propuesto. El CFIA de los componentes permitirá identificar
los componentes más débiles (vulnerabilidad y amplitud del impacto) que requie-
ren establecimiento de contramedidas de refuerzo.
Análisis de las paradas del servicio (SOA, Service Outage Analysis). Análisis a
posteriori de las causas de las caídas de un servicio, con el fin de reducir la frecuen-
cia y duración de las paradas. De forma similar se utiliza el término SFA (Service
Failure Analysis). Toma como fuente de información los incidentes ocurridos, para
realizar un análisis forense de cara a mejorar la disponibilidad.
Arquitectura de disponibilidad. Definición tecnológica que establece la forma
homogénea de construir servicios en la organización para que se cumplan los requi-
sitos de disponibilidad. Esta arquitectura establece la redundancia de componentes,
99,99%

el balanceo de carga y otros aspectos que refuercen la robustez y escalabilidad de

los servicios. Normalmente la arquitectura contempla varias soluciones: unas para los
servicios más críticos y más demandantes de disponibilidad, y otras para los menos
críticos. La arquitectura define primero y desarrolla después las especificaciones téc-
nicas. Se recomienda que, a partir de la arquitectura se construyan plataformas técni-
cas que alojen los servicios. Así, cada nuevo servicio no requerirá la compra de nuevo
equipamiento, sino que se incorporará a la plataforma previamente preparada. De
esta forma se facilita la consolidación de la infraestructura y su virtualización.
Arquitectura de continuidad. De forma similar y sincronizada con la arquitectura
de disponibilidad, en este caso se define la solución técnica para que los servicios se
puedan recuperar en caso de desastre. Debe contemplar varios tipos de soluciones
para cada una de las necesidades de recuperación de los servicios (definidas según
la criticidad de los mismos). Esta arquitectura proporciona las especificaciones téc-
nicas para implementar las opciones de recuperación, como por ejemplo, la recupe-
ración inmediata (conocida normalmente como mirroring), la recuperación rápida
(aunque conocida como hot standby), la recuperación intermedia (warm standby), la
recuperación gradual (cold standby), acuerdos recíprocos o soluciones manuales.
Ciclo de vida expandido del incidente. Detalle que se realiza sobre las diversas
fases en las que se descompone un incidente, con el fin de poder medir cada una de
ellas y determinar acciones correctoras para mejorar su resolución.
Clientes. Son los destinatarios o usuarios de los servicios. Expresan sus necesida-
des de disponibilidad y continuidad en los contratos y SLA.
CRAMM (CCTA, Risk Analysis Methodology Management). Método creado en
1987 por la Agencia Central de Procesamiento de Datos del Reino Unido (CCTA)
para identificar los riesgos y establecer las contramedidas justificadas con el fin de
reducir o eliminar las amenazas de tales riesgos. La evaluación de riesgos se divide
en tres etapas, las dos primeras identifican y analizan los riesgos en los servicios, y
la tercera recomienda cómo se deben gestionar estos riesgos. El método CRAMM
es uno de los más utilizados en la evaluación de riesgos para la continuidad, pero
también es válido para analizar los aspectos de la disponibilidad.
Diseño para la disponibilidad y continuidad. Conjunto directrices técnicas para
que la construcción de los servicios tenga la robustez necesaria para cumplir los
requisitos de disponibilidad y continuidad establecidos. El diseño debería llevar a
la definición de una arquitectura detallada, que posteriormente se debería imple-
mentar como plataforma consolidada que aloje los servicios.
Evaluación de riesgos. Se trata de una actividad que contextualiza los servicios en
el entorno en que éstos van a ser prestados. Proporciona información relativa a las
amenazas y vulnerabilidades que pueden afectar a los servicios, así como, la proba-
bilidad de que ocurran. El riesgo es función de la amenaza (probabilidad de que
ocurra el suceso) y de la vulnerabilidad de los servicios al mismo. La evaluación de

riesgos se puede realizar bajo varias perspectivas, dependiendo del proceso que lo
realice, para asegurar la disponibilidad de los sistemas (foco en fallos cotidianos), la
continuidad (foco en contingencias severas) o en la seguridad (foco en la malicia
humana).
Elemento de configuración. La infraestructura de TI con la que se presta el servi-
cio es la base sobre la que se articula y monitoriza tanto la disponibilidad, mediante
el seguimiento de la disponibilidad de cada uno de los componentes, como la con-
tinuidad, mediante los correspondientes planes. Todo ello teniendo en cuenta las
necesidades del negocio pactadas con los clientes y reflejadas en los SLA.
Función vital de negocio (VBF, Vital Business Function). Se utiliza el término
“función vital de negocio” para reflejar el conjunto de actividades sin las cuales el
negocio no se sustenta o se producen cuantiosas pérdidas. Normalmente se obtie-
nen como resultado del análisis del impacto en el negocio (BIA) de los riesgos. El
foco se centra en aquellas VBF que se sustentan en servicios de TI.
Gestión de la disponibilidad de TI (AM, Availability Management). Proceso que
gestiona todos los aspectos para poder garantizar los niveles de disponibilidad pac-
tados por TI con los clientes.
Gestión de la continuidad del negocio (BCM, Business Continuity Management).
Conjunto de acciones y actividades en la empresa u organización destinadas a
garantizar la supervivencia del negocio en el caso de que ocurra una catástrofe. Su
ámbito es toda la actividad, departamentos de la empresa y procesos de negocio.
Gestión de la continuidad del servicio de TI (ITSCM, IT Service Continuity
Management). Proceso específico en el ámbito de TI, que garantiza la superviven-
cia de los servicios de TI y de la información que contienen. Forma parte de la con-
tinuidad de negocio y desarrolla la continuidad específica en TI.
Informes de cumplimiento de planes. Evidencian el grado de ajuste entre lo
recogido en los planes y la realidad. En caso de desviación, analizan las circunstan-
cias que han llevado a esa situación.
M_o_R (Management of Risk). Metodología para la gestión de los riesgos pro-
puesta en ITIL v3, similar a CRAMM. Está estructurada en 5 etapas: políticas,
aproximación, proceso, institucionalizar y revisar, y comunicar.
Plan de continuidad de los servicios de TI (ITSCP, IT Service Continuity Plan).
Su elaboración es el eje central que articula todas a las acciones de continuidad. Se
elabora como parte del plan de continuidad del negocio.
Plan o planes de recuperación de los servicios de TI. Forman parte del ITSCP y
contienen todos los detalles para actuar en el caso de desastre, realizar la recupera-
99,99%

ción de los servicios, las infraestructuras, las telecomunicaciones, la alimentación

eléctrica, los servidores, etc.
Plan de disponibilidad. Recoge las políticas, requisitos, directrices y toda
la información necesaria para implementar y gestionar la disponibilidad de los
servicios. Es el documento sobre el que se articula la implantación de la dispo-
nibilidad.
Plan de paradas planificadas (PSO, Projected Service Outage). Documento que
refleja los intervalos en los que los servicios se pueden parar con fines de manteni-
miento o de cambio. Sirve como entrada para los requisitos del diseño, para los
acuerdos con los clientes, para la planificación de los cambios, etc.
Porcentaje de disponibilidad. Tiempo en el que los servicios han podido ser utili-
zados frente al tiempo total que los servicios deberían haber estado operativos. Es
la métrica de TI por excelencia.
Punto único de fallo (SPOF, Single Point Of Failure). Técnica para identificar ele-
mentos no redundados que, en caso de fallar, producirían una caída del compo-
nente o del servicio.
Requisitos de continuidad. Establecidos en la estrategia de TI y concretados en
los acuerdos de nivel de servicio con los clientes, son relativos a la continuidad
a cumplir por los servicios. En los requisitos de continuidad, para cada servicio,
se definen dos parámetros esenciales necesarios en el diseño de las soluciones: el
punto de recuperación (RPO, Recovery Point Objective) y el tiempo de recuperación
(RTO, Recovery Time Objective).
Requisitos de disponibilidad. Establecidos en la estrategia de TI y concretados
en los acuerdos de nivel de servicio con los clientes relativos a los niveles de dispo-
nibilidad a cumplir. Establecen el porcentaje de disponibilidad de los servicios, los
tiempos de respuesta, los horarios del servicio, etc.
RPO (Recovery Point Objective) o punto objetivo de recuperación. Representa la
pérdida de información máxima que el negocio está dispuesto a asumir en un servi-
cio después de un desastre.
RTO (Recovery Time Objective) o plazo objetivo de recuperación. Tiempo máximo
en el que se debe recuperar un servicio tras un desastre.
Tiempo de respuesta. Lapso de tiempo en que tarda un servicio online en respon-
der al usuario. Un tiempo de respuesta por encima de los límites se considera indis-
ponibilidad del servicio. Se pactan con los clientes. En sistemas transaccionales
rabiosos o críticos se considera que debe estar por debajo de los 3 segundos, en
páginas web en Internet el usuario está acostumbrado y da por bueno tiempos
de espera superiores, llegando en algunos casos a superar los 10 segundos.
Entradas, actividades y salidas de la gestión de la

disponibilidad
La gestión de la disponibilidad se encarga de garantizar que los servicios son capa-
ces de cumplir los requisitos de disponibilidad y tiempo de respuesta que se han
pactado con el negocio. Sus actividades se pueden considerar divididas en dos gran-
des grupos: uno primero destinado a planificar e implementar las soluciones de dis-
ponibilidad y, un segundo, que realiza la gestión operativa de la misma.
En el esquema de la figura 6.3.7 se muestran las entradas, actividades y salidas de
la gestión de la disponibilidad. Las actividades de disponibilidad y continuidad se
DISPONIBILIDAD
Desencadenantes 3 Inicio: Salidas principales:

del proceso: • Política disponibilidad. Ü Plan de disponibilidad.
Ü Petición de la dirección. • Definición e inicio proyecto. Ü Funciones vitales del
Ü Negociación de un SLA. negocio-VBF.
3 Requerimientos y estrategia:
Ü Incumplimiento Ü Directrices de diseño
• Evaluación de riesgos.
disponibilidad. de la disponibilidad y
• Determinar requisitos. arquitectura.
Ü Fecha revisión del plan
disponibilidad. 3 Implementación: Ü Informes de
seguimiento de
• Diseñar para la disponibilidad.
Entradas de soporte: disponibilidad.
• Diseñar para la recuperación.
Ü Riesgos.
• Verificar la seguridad. Salidas secundarias:
Ü SLA firmados.
• Planificar las paradas. Ü Requisitos de
Ü Información de
monitorización.
incidentes y problemas. • Generar el plan de
disponibilidad. Ü Plan paradas
Ü Datos de monitorización .
planificadas-PSO.
Ü RFC. 3 Gestión operativa:
Ü Resultados análisis de
Ü CMDB. • Supervisar la disponibilidad. riesgos.
• Investigar y mejorar Ü Resultados técnicos
disponibilidad. investigación incidentes.
• Actualizar plan de
disponibilidad.
3 Mejora del proceso
Figura 6.3.7. Entradas, actividades y salidas de la gestión de la disponibilidad

99,99%

han estructurado de forma pareja para facilitar su integración como un proceso

único. Además, ambas emulan la estructura utilizada en ITIL para la continuidad.
La gestión de la disponibilidad se inicia con una petición de la dirección de TI para
que se realice el ciclo de planificación de la disponibilidad, que termina con el plan
de disponibilidad realizado o actualizado. El inicio de la negociación de un acuerdo
de nivel de servicio también puede activar el proceso con el fin de apoyar a la ges-
tión de nivel de servicio en los aspectos relativos a la disponibilidad. El incumpli-
miento de los niveles de disponibilidad, detectados por otros procesos o áreas, tam-
bién puede desencadenar que se inicien las acciones de investigación y mejora de la
disponibilidad. Además, el proceso se activa por la proximidad de la fecha de revi-
sión del plan de disponibilidad.
La gestión de la disponibilidad utiliza como entradas de soporte: información
sobre los distintos riesgos e información técnica de los componentes; información
sobre los incidentes y los problemas con el fin de analizar las causas de fallo; datos
de monitorización para el seguimiento de la disponibilidad y las tendencias; peti-
ciones de cambio (RFC) con el fin de velar porque no se pongan en riesgo los nive-
les de disponibilidad y para mantener actualizado el plan de disponibilidad con los
cambios realizados; y la base de datos de gestión de la configuración (CMDB) para
obtener los detalles de los elementos de configuración que componen los servicios.
Las principales actividades de la gestión de la disponibilidad se han articulado en
torno a conceptos similares utilizados en la gestión de la continuidad de ITIL.
En este libro se han añadido las fases de inicio y de requerimientos y estrategia. Las
actividades que se deben realizar son:
• Inicio. Establece las condiciones para el comienzo de la implantación de la
gestión de la disponibilidad.
– Definir las políticas de disponibilidad. Se fijan las directrices que se
deben cumplir por la disponibilidad de los servicios.
– Definición e inicio del proyecto de disponibilidad. Se crea el proyecto
para implementar la disponibilidad, con su planificación y dotación presu-
puestaria. Se inicia su ejecución.
• Requerimientos y estrategia. Establece los requerimientos que se deben

cumplir en relación a la disponibilidad.
– Realizar la evaluación de riesgos. Identifica las funciones vitales del
negocio (VBF) y realiza el análisis de riesgos.
– Determinar los requisitos de disponibilidad. Se deben establecer los requi-
sitos que deben cumplir los servicios en cuanto a la disponibilidad y tiempo
de respuesta. Se define la estrategia que se debe seguir para satisfacerlos.
• Implementar la disponibilidad. Actividades para implantar la disponibilidad.

– Diseñar para la disponibilidad. Definición de las directrices de diseño
de los servicios (en cuanto a la disponibilidad y tiempo respuesta). Deri-
vado de estas directrices se suele y se deben definir unas arquitecturas téc-
nicas y unas plataformas que alojen los servicios.
– Diseñar para la recuperación. Fija las pautas y procedimientos de actua-
ción en caso de que se produzca un incidente de pérdida de disponibili-
dad, que deberá ejecutar la gestión del incidente.
– Verificar la seguridad. Asegura que se implantan las medidas de seguri-
dad adecuadas en los componentes del servicio.
– Planificar las paradas y el mantenimiento. De forma general, todo ser-
vicio requiere en algún momento de su prestación la realización de tareas
de mantenimiento. El mantenimiento de los servicios debe llevarse a cabo
de forma que se minimice su impacto sobre el servicio y su disponibilidad,
utilizándose cuando es posible las denominadas ventanas de manteni-
miento (paradas planificadas). Para poder aprovechar las mencionadas
ventanas de mantenimiento es necesario tener identificado cuándo se
requiere el mantenimiento y cuáles son las actividades que implica (rela-
ción con el proceso de gestión del cambio). Determina las ventanas de
parada de componentes y de los servicios, para mantenimiento o para la
realización de cambios.
– Generar el plan de disponibilidad. Todos los resultados de las activida-
des anteriores se recogen en el documento central del proceso: el plan de
disponibilidad, que aglutina en un documento toda la información e ini-
ciativas necesarias para mejorar la disponibilidad.
• Gestión operativa. Gestión diaria de la disponibilidad de los servicios en

producción.
– Supervisión de la disponibilidad. Prepara los medios necesarios para
realizar un seguimiento de la disponibilidad obtenida de los componentes
y de los servicios: define las métricas, define los informes, especifica los
umbrales de monitorización, genera los informes necesarios sobre la dis-
ponibilidad obtenida y comunica los resultados a las partes interesadas.
Dentro de esta actividad, también se puede incluir la definición de las
herramientas de monitorización necesarias y su implementación; aunque
lo habitual es definir un proyecto específico para implantar todo el con-
junto de herramientas de monitorización necesarias para todos los proce-
sos y para las funciones técnicas.
99,99%

– Investigar y mejorar la disponibilidad. Analiza las causas de la no dispo-

nibilidad e identifica las áreas de mejora en los componentes y servicios para
que los valores de disponibilidad se ajusten a los requeridos por el negocio.
– Actualizar el plan de disponibilidad. Se actualiza el plan de disponibili-
dad de forma periódica, realizando una revisión completa de su contenido.
Además, se actualiza con los cambios realizados en la infraestructura.
• Mejorar el proceso. Conjunto de actividades destinadas a la revisión del

proceso de la gestión de la disponibilidad para mejorar su eficiencia.
Las actividades de gestión de la disponibilidad se representan en el esquema de la

figura 6.3.8, que simula un esquema legendario de ITIL v2 para la gestión de la
continuidad.
GESTIÓN DE LA DISPONIBILIDAD
Política
Inicio Definición e inicio
del proyecto
Requerimientos Evolución de riesgos

y estrategia Determinar requisitos
PLANIFICAR
Diseñar para la
Implementación
disponibilidad
Diseñar para
Verificar la seguridad Planificar las paradas
la recuperación
Generar el plan de disponibilidad
Gestión • Métricas
operativa Supervisar la Investigar y mejorar
• Monitorizar
disponibilidad la disponibilidad SUPERVISAR
• Informes
Actualizar el plan de disponibilidad
Mejora del proceso

Fuente: Libros ITIL Provisión de Servicio y Diseño del Servicio publicados por OGC y e.p.
Figura 6.3.8. Actividades de la gestión de la disponibilidad

La salida tangible principal de la gestión de la disponibilidad es el documento

denominado “plan de disponibilidad”. También quedan claramente identificadas
las funciones vitales del negocio (VBF). Se generan las directrices de diseño y la
arquitectura para la disponibilidad. Asimismo, se producen los informes de segui-
miento sobre la disponibilidad y tiempo de respuesta obtenidos de los servicios.
Como salidas secundarias se producen el documento de requisitos de disponibili-
dad a cumplir; los requisitos y las especificaciones para la monitorización de la dis-
ponibilidad, con los umbrales y alarmas correspondientes; el plan de paradas plani-
ficadas (PSO); los resultados para el análisis de riesgos; y los resultados técnicos de
las investigaciones “forenses” de las indisponibilidades o fallos ocurridos.
Requerimientos y estrategia de la disponibilidad

Después de la fase de inicio, en la que se definen las políticas y el plan de proyecto
para implantar el proceso de disponibilidad, comienza la fase de requisitos y estra-
tegia. En esta fase se realiza el análisis de los riesgos y se determinan los requisitos
a cumplir en cuanto a la disponibilidad. Las actividades son:
Realizar la evaluación de riesgos. Para realizar el análisis de riesgos de pérdidas
de disponibilidad existen varias técnicas o métodos implantados en el mercado.
Normalmente se suele utilizar CRAMM. La evaluación de los riesgos utiliza méto-
dos similares en disponibilidad y en continuidad, pero el objeto del análisis es dis-
tinto. En el primero se identifican los fallos normales que puedan producir indis-
ponibilidad, y en el segundo se identifican los eventos especiales que generen una
grave pérdida. Por otra parte, las contramedidas que se deben implantar también
suelen ser diferentes.
En esta actividad se identifican también las funciones vitales del negocio (VBF),
aquéllas cuyo fallo causarían una grave pérdida en el negocio. Si se está implan-
tando también la continuidad, esta actividad es común a ambas disciplinas.
A partir de la definición de las VBF, el tratamiento y la concepción de la disponibi-
lidad, los servicios de TI se suelen dividir en dos grandes bloques: los servicios crí-
ticos que soportan una o varias VBF, que son tratados con el mejor de los esmeros,
y el resto de servicios. Esta división permitirá concentrarse especialmente en los
servicios que realmente importan al negocio, y puede dar lugar a plantear arquitec-
turas, presupuestos o estrategias de sourcing completamente distintas para cada uno
de los bloques.
Determinar los requisitos de disponibilidad. Se deben establecer los requisitos
que deben cumplir los servicios en cuanto a la disponibilidad y tiempo de res-
puesta, estructurados por tipo de funcionalidad y criticidad. Estos valores, o rangos
99,99%

de valores, servirán de entrada en la negociación de los acuerdos del nivel de servi-

cio y, consecuentemente, en el diseño técnico y del soporte de los mismos.
A este respecto, las Normas ISO/IEC 20000 son claras en sus exigencias, especifi-
cando que los requisitos se establezcan teniendo en cuenta los planes de negocio,
los SLA y las evaluaciones del riesgo realizadas. Los requisitos deben incluir los
derechos de acceso a los servicios, los tiempos de respuesta necesarios y la disponi-
bilidad integral de los servicios.
UNE-ISO/IEC 20000-1
Se deben identificar los requisitos de disponibilidad y de continuidad del servicio

sobre la base de los planes de negocio, los SLAs y las evaluaciones del riesgo. Los
requisitos deben incluir los derechos de acceso y los tiempos de respuesta, así como,
la disponibilidad extremo a extremo de los componentes del sistema.
ISO/IEC 20000-2 recomienda, además, que se dote de los recursos necesarios para
poder satisfacer estos requisitos en cualquier circunstancia. Insta también a que se
trabaje de forma integrada entre la gestión de la disponibilidad y la continuidad.
También detalla el concepto de “extremo a extremo” mencionado en la parte 1,
incluyendo todos los elementos que sustentan el servicio con independencia de
quién dependan: del proveedor principal o bajo el control, bien del propio cliente,
o de otros proveedores de servicio.
UNE-ISO/IEC 20000-2
Generalidades caídas graves del servicio. El proveedor

del servicio debería planificarse para
Los requisitos de continuidad y disponi-
satisfacer los datos conocidos de incre-
bilidad se deberían identificar sobre la
mentos o decrementos de volumen de
base de las prioridades del negocio del
usuarios, picos o caídas previstos de la
cliente, los acuerdos de nivel de servicio
demanda y cualquier otro cambio futuro
y los riesgos evaluados. El proveedor
conocido. Los requisitos deberían incluir
del servicio debería mantener una capa-
los derechos de acceso y los tiempos de
cidad suficiente para el servicio junto
respuesta así como la disponibilidad de
con planes fácilmente realizables, dise-
los componentes del sistema.
ñados para asegurar que los requisitos
acordados pueden ser alcanzados en La gestión de la disponibilidad y continui-
todas las circunstancias, desde el fun- dad del servicio debería trabajar conjun-
cionamiento habitual hasta los casos de tamente con el objetivo de asegurar que
se mantengan los niveles de servicio Los procesos que aseguran que se man-
acordados. Estos requisitos deberían tiene la disponibilidad requerida, debe-
tener una influencia capital en las accio- rían incluir aquellos elementos de la
nes, esfuerzos y recursos destinados para provisión del servicio que estén bajo el
satisfacer la disponibilidad de los servi- control bien del propio cliente o de
cios que los soportan. otros proveedores del servicio.
Los requisitos de disponibilidad deben estar recogidos en términos y condiciones

cuantificables para evitar cualquier confusión o malentendido entre el negocio y la
organización de TI. La cuantificación de la disponibilidad permitirá determinar las
necesidades y los costes para alcanzar los niveles de servicio necesarios.
Los requisitos de disponibilidad deben especificar:
• Las funciones clave o vitales para el negocio.
• El impacto sobre el negocio causado por la pérdida de los servicios.
• El grado en el que el negocio puede tolerar una caída o degradación de un
servicio.
• Descripción de la importancia relativa de los diferentes horarios de trabajo
para cada servicio.
• El porcentaje de disponibilidad mensual mínimo admisible por el negocio
para los servicios. En ocasiones se detalla también para los servicios críticos
la parada máxima en minutos admisible por franja horaria.
• Las condiciones bajo las cuáles el negocio considera que un servicio no está
disponible, incluyendo el límite permitido del tiempo de respuesta en
segundos.
• Las franjas horarias necesarias para los servicios y las ventanas de manteni-
miento.
• Las necesidades específicas de seguridad.
La aceptación de estos requisitos conlleva la definición de la estrategia a cumplir

por el proceso de disponibilidad. Los requisitos pueden variar según la criticidad
del servicio, y estar balanceados con el escenario económico del negocio y el coste
de la tecnología necesaria para cumplirlos. Estos requisitos formarán parte de la
definición de los servicios y estarán recogidos en los correspondientes SLA.
99,99%

Implementar la disponibilidad
Definidos los requisitos que se deben cumplir, se inicia la fase de implementar el
proceso (o subproceso) de gestión de la disponibilidad. En la implementación
se realizan las actividades siguientes: diseñar para la disponibilidad, diseñar para la
recuperación, verificar la seguridad, planificar las paradas y mantenimiento, y generar
el plan de disponibilidad.
Diseñar para la disponibilidad. A la hora de diseñar un servicio o de realizar una

modificación, uno de los aspectos siempre presentes serán los requisitos de dispo-
nibilidad. La finalidad del diseño es crear una infraestructura robusta de TI que
pueda cumplir los niveles de disponibilidad demandados.
A partir de los requisitos, se establecen las directrices y los estándares de disponibilidad
del servicio que habrán de cumplirse en los diseños, tanto por el desarrollo de aplica-
ciones, como en la construcción de las infraestructuras hardware y software asociadas.
El diseño debe proporcionar soluciones que garanticen la disponibilidad requerida por
cada tipo de servicio, así como, el tiempo de respuesta en situaciones pico de carga.
En la figura 6.3.9 se muestra la fórmula típica de la disponibilidad y lo que ésta
representa en tiempo de parada mensual acumulado. Nótese que cuanto menor es
el horario de servicio, una misma tasa de disponibilidad permite un tiempo acumu-
lado de parada menor.
Cálculo de la disponibilidad
Tiempo real de servicio

% disponibilidad = x 100
Tiempo esperado de servicio
Tiempo mensual de caída permitido (horas)
Período de servicio: 24 x 7 24 x 5 12 x 5
Horas/mes de servicio: 720 horas 480 horas 240 horas
% disponibilidad:
99,999% 25,92 seg 17,28 seg 8,64 seg
99,99% 4,32 min 2,88 min 1,44 min
99,98% 8,64 min 5,76 min 2,88 min
99,90% 43,2 min 28,8 min 14,4 min
99,00% 7,2 horas 4,8 horas 2,4 horas
98,00% 14,4 horas 9,6 horas 4,8 horas
95,00% 1,5 días 24 horas 12 horas
Figura 6.3.9. Cálculo de la disponibilidad

Es recomendable, dentro del diseño, acometer la definición de una o varias arqui-

tecturas, que establecerán la forma homogénea de construir los servicios. Una vez
fijadas las directrices tecnológicas en la arquitectura, se implementan en una o
varias plataformas (hardware, software y comunicaciones), sobre las que se irán
incorporando los servicios. Explotar los servicios sobre una plataforma común
tiene máxima importancia en la actualidad, teniendo en cuenta las tendencias de
consolidación de infraestructuras y la virtualización del equipamiento (servidores y
almacenamiento). La actividad técnica necesaria en este proceso será realizada por
los grupos técnicos: arquitectos, técnicos de sistemas, especialistas, etc., trabajando
a tiempo parcial para el proceso.
Para cada servicio, o por lo menos para los críticos, conviene realizar el análisis del
árbol de fallos (FTA, Fault Tree Analysis) con el fin de identificar los puntos únicos
de fallo (SPOF, Single Point Of Failure). Esta identificación de vulnerabilidades y
puntos débiles permitirá eliminarlos o mitigarlos en la fase de diseño, antes de su
construcción.
Diseñar para la recuperación. Dentro de las actividades que se realizan en el diseño

del servicio está la de diseñar para la recuperación. Se trata de una actividad proac-
tiva cuyo objetivo es identificar aquellos elementos que, ante un fallo, tienen que
volver a prestar servicio lo antes posible. La gestión de la disponibilidad también
debe fijar las pautas de actuación que deben seguirse, cuando un incidente afecta a
los componentes críticos del servicio, para el restablecimiento de las operaciones.
El diseño para la recuperación contempla la identificación de las necesidades de
información que tiene el negocio para permitirles gestionar el impacto del fallo, y
las necesidades de la propia organización de TI en cuanto a procesos, procedimien-
tos y herramientas y soporte externo para que pueda ejecutar la recuperación.
Verificar la seguridad. La gestión de la disponibilidad se ocupa de la disponibili-

dad de todos los componentes de los servicios de TI, incluidos los datos. Por tanto,
la gestión de la disponibilidad está estrechamente relacionada con el proceso de
gestión de la seguridad de la información. Asegura que se implantan las medidas
de seguridad adecuadas en los componentes del servicio.
Los requisitos de seguridad identificados se transmiten al responsable de la gestión
de la seguridad. Entre ellos se encuentran:
• Los productos y servicios deben estar únicamente a disposición del personal
autorizado. Esto también es aplicable a los datos gestionados.
• Los productos y servicios deben poder recuperarse después de un fallo para
garantizar que no se compromete la confidencialidad y la integridad, y que
la disponibilidad del servicio no vuelve a peligrar.
99,99%

• Se deben poder recuperar los productos y servicios dentro de unos paráme-

tros seguros, es decir, que no debe comprometerse la política de seguridad
de TI existente en la organización
Estos compromisos forman parte de los requisitos de disponibilidad de los servi-

cios. Además, se propone que estos requisitos queden recogidos en un acuerdo
interno entre gestión de la disponibilidad y la gestión de la seguridad.
Planificar las paradas (PSO, Projected Service Outage). Parte de la gestión de la dis-
ponibilidad es la gestión del mantenimiento del servicio (planificación de las para-
das) tanto a efectos propios del mantenimiento como para la incorporación de
cambios. Organiza las actividades de mantenimiento dentro de los períodos y ven-
tanas (planificaciones de parada para el mantenimiento de los sistemas o para la
implantación de cambios) en los que se minimiza el impacto sobre la disponibili-
dad del servicio.
Se genera el plan de paradas planificadas (PSO) en el que se definen los períodos
diarios, semanales o mensuales en los que se pueden parar los servicios. Se trata de
un elemento básico para minimizar el impacto en el negocio de estas actividades.
Además, las ventanas de parada se suele excluir en el cálculo de la disponibilidad
real del servicio.
Generar el plan de disponibilidad. El plan de disponibilidad es un plan a

futuro que cubre un período de entre uno y dos años. Su objetivo es mejorar la
disponibilidad general de la infraestructura de TI para asegurar que se pueden
alcanzar los niveles de disponibilidad de una manera eficiente, tanto actuales,
como futuros.
Este plan es uno de los resultados principales del proceso que aglutina toda la infor-
mación generada en él. Conviene distinguirlo del proyecto de implementación del
propio proceso de gestión de la disponibilidad (véase la fase de inicio). Los conte-
nidos tipo del plan de disponibilidad se muestran en la figura 6.3.10.
Gestión operativa de la disponibilidad

Una vez implantados los servicios y puestos en producción, el proceso de gestión
de la disponibilidad se mantiene activo y vigila diariamente los servicios, en cuanto
a los aspectos de disponibilidad y tiempo de respuesta. La gestión operativa com-
prende las actividades de supervisión de la disponibilidad, la investigación de la
causa de los fallos para mejorar la disponibilidad y la actualización del plan de dis-
ponibilidad.
Plan de disponibilidad
3 Política de disponibilidad.
3 Riesgos identificados.
3 Requisitos de la disponibilidad y estrategia.
3 Funciones vitales del negocio (VBF).
3 Directrices de diseño de servicios.
3 Arquitectura de los servicios enfocada a la
disponibilidad y tiempo de respuesta.
3 Definición de las plataformas tecnológicas que se
van a utilizar.
3 Horarios de los servicios.
3 Plan de recuperación y procedimientos.
3 Plan de paradas planificadas (PSO). Ventanas de
mantenimiento y cambio.
3 Requisitos de seguridad.
3 Herramientas de monitorización.
3 Métricas de disponibilidad que se van a utilizar.
3 Modelos de informes de disponibilidad.
3 Fijar los métodos y técnicas de análisis a utilizar.
3 Planificación de la mejora de la disponibilidad.
3 Análisis tendencias tecnológicas.
Figura 6.3.10. Contenido tipo de un plan de disponibilidad y

del plan de recuperación asociado
Supervisión de la disponibilidad. Vela por que se cumplan los compromisos de

disponibilidad de los servicios. Para ello establece las métricas de la disponibilidad,
gestiona la implementación de las herramientas de monitorización para la obten-
ción de las métricas y confecciona los informes de disponibilidad.
Como se indica en ISO/IEC 20000, se debería registrar la disponibilidad del servi-
cio. Las mediciones se utilizan para comparar los resultados con los valores estable-
cidos en los SLA y analizar los posibles incumplimientos. Esto se realiza de forma
conjunta con gestión de nivel de servicio.
99,99%

UNE-ISO/IEC 20000-1
La disponibilidad se debe medir y registrar. Se debe investigar la no disponibilidad

no planeada y se deben llevar a cabo las acciones necesarias.
Nota: Cuando sea posible, se deben predecir problemas potenciales y tomar medidas preventivas.
Estas medidas e informes de disponibilidad deben reflejar las perspectivas del nego-
cio, de los usuarios y de la organización de soporte. Se analizan las tendencias y
posibles desviaciones, se estudian las tendencias de la disponibilidad de los compo-
nentes de la infraestructura y se comunican los resultados a las partes interesadas.
UNE-ISO/IEC 20000-2
Actividades y supervisión de la d) documentar y revisar las no con-

disponibilidad formidades;
La gestión de la disponibilidad debería: e) predecir la disponibilidad a futuro;
a) supervisar y registrar la disponibi- f) cuando sea posible, se deberían

lidad del servicio; predecir los posibles problemas y
llevar a cabo las acciones preven-
b) mantener datos históricos precisos;
tivas.
c) realizar comparaciones con los
requisitos definidos en los SLA Se debería asegurar la disponibilidad
para identificar no conformidades de todos los componentes del servicio,
con los objetivos de disponibili- registrando y llevando a cabo las accio-
dad acordados; nes correctivas.
Investigar y mejorar la disponibilidad. Consiste en revisar la disponibilidad

de los servicios y los componentes para identificar las áreas de incumplimiento o de
perfeccionamiento. La investigación se centra en identificar las áreas de mejora en
los servicios para que los valores de disponibilidad se incrementen. Las mejoras se
incorporan en el plan de disponibilidad y en el plan de mejora unificado de los pro-
cesos y de los servicios (véase el capítulo 4).
Es conveniente aclarar la frontera entre la gestión del problema y la investigación
de la disponibilidad con el fin de evitar conflictos de intereses. La investigación de
la disponibilidad puede conllevar la necesidad de abrir un problema que será tra-
tado bajo la gestión del problema. La gestión del problema parte de un incidente o
de un conjunto de ellos para determinar la causa raíz que lo provocó y resolverlo
provisional o definitivamente. La investigación de la gestión de la disponibilidad

va más allá de la causa de los incidentes, es más general. Se mueve por estadísticas,
informes, tendencias o incumplimientos, para proponer soluciones. La gestión del
problema también tiene una parte proactiva que también investiga las tendencias.
Los aspectos que analiza la investigación de la disponibilidad tienen relación con:
• Las tendencias de la gestión de la disponibilidad.
• Un deterioro gradual de las mediciones de la disponibilidad.
• La incapacidad de un servicio para satisfacer la disponibilidad requerida.
• La identificación de períodos de inestabilidad del servicio.
• Tiempos de recuperación y restauración del servicio inaceptables.
• Solicitudes por parte del negocio para incrementar el nivel de disponibilidad.
• La solicitud, por parte de la gestión de niveles de servicio, para mejorar la
disponibilidad como parte de un programa de mejora del servicio.
Actualizar el plan de disponibilidad. De forma periódica, y por lo menos una vez

al año, se debe actualizar el plan de disponibilidad realizando una revisión completa
de su contenido, desde la política hasta el análisis de tendencias tecnológicas. Ade-
más, se actualiza de forma continua con los cambios que se vayan realizando en la
infraestructura, identificados a través del proceso de gestión del cambio.
ISO/IEC 20000-1 es clara a este respecto e incluye también en los requerimientos
a los planes de continuidad:
UNE-ISO/IEC 20000-1
Los planes de disponibilidad y continuidad del servicio se deben desarrollar y revisar

al menos una vez al año, para asegurar que los requisitos cumplen lo acordado bajo
todas las circunstancias, desde la normalidad hasta la pérdida grave del servicio.
Estos planes se deben mantener para asegurar que reflejan los cambios acordados,
requeridos por el negocio.
Los planes de disponibilidad y de continuidad del servicio se deben probar de nuevo

cuando se produzca un cambio importante en el entorno del negocio.
El proceso de gestión del cambio debe evaluar el impacto de cualquier cambio

sobre los planes de disponibilidad y de continuidad del servicio.
99,99%

Mejora del proceso de disponibilidad

Se debe revisar el propio proceso para mejorar su operativa y subsanar sus fallos e
ineficiencias. Las mejoras propuestas pueden estar relacionadas con alguna de las
actividades del proceso o con otros procesos, por ejemplo, la gestión de nivel de
servicio. Nuevamente, las mejoras se centralizan en el plan de mejora unificado
(véase el capítulo 4).
Entradas, actividades y salidas del proceso de gestión de

la continuidad de TI
La misión de la gestión de la continuidad de TI es preparar las infraestructuras y su
gestión para que resistan y sobrevivan a las consecuencias de un suceso catastrófico
o devastador en la empresa, como por ejemplo, un incendio, una inundación en el
centro de datos, una contaminación masiva de servidores por virus, un ataque exte-
rior, un terremoto, actos vandálicos, etc. Estos hechos pueden parecer remotos o
de probabilidad muy baja, pero TI no está tan a salvo como cree. Una simple
rotura de una tubería puede inundar el centro de datos o provocar un desastre eléc-
trico. Los ataques de los virus están a la orden del día. Que se contaminen los ser-
vidores es un suceso cada vez más probable.
La gestión de la continuidad de los servicios de TI se centra en garantizar el cum-
plimiento de los requisitos acordados tras una interrupción del negocio provocado
por una catástrofe.
La gestión de la continuidad también está desarrollada en la normativa internacional.
La serie de normas británicas BS 25999 (Business continuity management) definen los
requisitos para un sistema de gestión de continuidad de negocio en base a un código
de buenas prácticas (parte 1) y unas especificaciones técnicas (parte 2) que son certifi-
cables. También existe normativa al respecto en Japón, Australia, Singapur, Austria, etc.
La gestión de la continuidad trabaja en la preparación anticipada y en el manteni-
miento permanente. Por ello, sus actividades se pueden considerar divididas en dos
grandes bloques: la planificación e implementación y la gestión operativa de la
misma. El primer bloque define claramente la estrategia e implementa las medidas
de salvaguardia. Este bloque se suele realizar como un proyecto de consultoría e
implantación. Dado que la continuidad de TI parte de un plan de continuidad del
negocio, la definición de la estrategia se entiende que la debe liderar algún área de la
empresa, normalmente la de seguridad general. En el segundo bloque, la actividad
se centra en mantener siempre frescos, en la mente de todos, los planes de continui-
dad y en estar preparado para responder inmediatamente a una contingencia.
En la gestión de la continuidad se ha seguido la misma estructura de actividades

planteada en ITIL. Las interacciones y funcionalidades de la gestión de la continui-
dad se resumen en la figura 6.3.11.
CONTINUIDAD
Desencadenantes 3 Inicio: Salidas principales:

del proceso: • Definir política continuidad. Ü Plan de continuidad.
Ü Plan de continuidad del • Ámbito de la continuidad. Ü Contratos de servicios
negocio. externos de continuidad.
• Definición e inicio proyecto
Ü Contingencia severa. continuidad. Ü Procedimientos y
Ü Fecha de pruebas. medios operativos de
3 Requerimientos y estrategia:
Ü Fecha revisión del plan. recuperación.
• Análisis impacto en el negocio.
Ü Infraestructura
Entradas de soporte: • Evaluación de riesgos. preparada.
Ü Acuerdos continuidad • Definición estrategia Ü Personal entrenado.
en SLA. continuidad.
Ü Informes resultados
Ü Riesgos. 3 Implementación: pruebas de continuidad.
Ü Presupuestos. • Realización plan continuidad
Salidas secundarias:
Ü Cambios. de TI.
Ü Requisitos de continuidad.
Ü CMDB. • Desarrollo plan recuperación.
Ü Plan proyecto continuidad.
Ü Información técnica. • Implementar medidas
recuperación. Ü Funciones vitales de
negocio (VBF).
• Implementar medidas
reducción riegos. Ü Evaluación de riesgos.
• Desarrollar procedimientos.
• Pruebas iniciales.
3 Gestión operativa:
• Educación y concienciación.
• Revisión y auditoría.
• Pruebas.
• Control de cambios.
• Formación.
• Aseguramiento.
• Gestión las contingencias
en TI.
3 Mejora del proceso
Figura 6.3.11. Entradas, actividades y salidas de la gestión de la continuidad

99,99%

Las entradas que desencadenan o activan el proceso son: la realización del plan de
continuidad de negocio por parte de la empresa, que requiere de TI la realización
de su contribución a este plan; el acaecimiento de una contingencia severa que
activa la ejecución de los procedimientos de continuidad; la llegada de la fecha pre-
vista de pruebas de continuidad, que inicia el protocolo de pruebas; y la proximi-
dad de la fecha de revisión del plan de continuidad.
Las entradas más relevantes que utiliza el proceso como información de soporte
son: las condiciones solicitadas o pactadas con los clientes en los acuerdos de nivel
de servicio (SLA); la información de los principales riesgos que amenazan a TI; los
presupuestos asignados a la continuidad, que condicionan las inversiones; los cam-
bios realizados en las infraestructuras o los servicios que deban contemplarse en las
soluciones de continuidad; la información sobre los elementos de configuración
contenida en la CMDB; y la información técnica diversa para proporcionar solu-
ciones o directrices.
Las actividades del proceso se estructuran en 5 grupos:
• Inicio. El primer paso es determinar sobre qué aspectos del negocio y de los
servicios va a actuar la continuidad de TI y sobre cuáles no.
– Definir política continuidad. Directrices y objetivos que establece la
dirección y principales responsabilidades.
– Ámbito de la continuidad. Localizaciones, unidades de negocio o servi-
cios que se deben cubrir. Normalmente no se debería restringir el ámbito.
– Definición del proyecto de continuidad. Plan detallado del proyecto de
implementación de la continuidad (de TI). Designación del responsable
máximo de plan y de los responsables en cada departamento o área. Pre-
supuesto para la definición del plan. Posteriormente se tendrá que hacer
una dotación adicional de presupuesto para la implantación de la solución
de continuidad. Organización de proyecto y estructura de control. Plan de
calidad del mismo. Lanzamiento del proyecto.
• Requerimientos y estrategia. Determinar los requisitos de continuidad del

negocio, así como la estrategia que se debe seguir para garantizar dicha con-
tinuidad.
– Análisis del impacto de un desastre. Repercusión en las infraestructuras
y en el negocio de los diversos tipos de paradas que pueden ocurrir. Iden-
tificación de las funciones vitales del negocio (VBF) si no se han determi-
nado previamente.
• Evaluación de riesgos. Estudio detallado de las amenazas y vulnerabili-
dades posibles y de la probabilidad de su ocurrencia.
– Definición de la estrategia de continuidad. Definición de la estrategia

de TI para mantener la continuidad de los procesos de negocio en caso de
ocurrir un desastre.
• Implementación. Elaborar los planes de continuidad y poner en marcha las

contramedidas necesarias para reducir el riesgo y desplegar las soluciones de
TI para mitigar el riesgo y recuperar el negocio en caso de desastre.
– Realización del plan continuidad de TI. Realización de todos los estu-
dios, análisis y diseños necesarios y confección de este documento esencial
de la continuidad.
– Desarrollo plan de recuperación. Definición de todas las medidas nece-
sarias para poder realizar la recuperación, abarcando personas, infraestruc-
turas y servicios externos necesarios.
– Implementar las medidas de recuperación. Adquirir, construir y poner
en funcionamiento las soluciones definidas.
– Implementar las medidas de reducción riegos. Puesta en marcha de las
contramedidas para la reducción de la exposición a las amenazas o de sus
efectos.
– Desarrollar los procedimientos. Instrucciones detalladas de actuación
para cada uno de los servicios y grupos de soporte.
– Realizar las pruebas iniciales. Pruebas completas y detalladas de las solu-
ciones implementadas, antes de dar por concluida la implementación
Incluyen a las personas, infraestructuras y servicios externos. Control final
de la calidad.
• Gestión operativa. Realiza el mantenimiento en activo de las soluciones de

continuidad, las pruebas, la formación y la divulgación de los planes de con-
tinuidad.
– Educación y concienciación de todo el personal de TI y del negocio.
– Revisión y auditoria sistemática y periódica de todo el plan y su imple-
mentación.
– Pruebas y simulacros de los planes de recuperación. Esta actividad, ade-
más incluye el análisis de los resultados de las pruebas como punto de
entrada a la mejora.
– Control de los cambios en el personal, la infraestructura y los servicios
externos. Actualización de los planes. Debe estar siempre coordinado con
el proceso de gestión del cambio.
99,99%

– Formación y entrenamiento del personal que deberá intervenir en los pla-

nes de recuperación y de reducción de riesgos.
– Aseguramiento, confianza o garantía a la dirección sobre la fiabilidad de
los planes y las medidas implementadas.
– Gestión de las contingencias en TI. Ocurrida la contingencia, ejecución
de lo previsto en el plan de continuidad y recuperación, para retornar a la
normalidad cuanto antes.
GESTIÓN DE LA CONTINUIDAD
Política de continuidad
Ámbito de la continuidad
Inicio
Definición e inicio
del proyecto
Análisis del impacto

BIA, VMF
en el negocio
Requerimientos
y estrategia Evolución de riesgos M_o_R, CRAMM
Estrategia de continuidad
Realizar el plan de
Plan de continuidad TI
continuidad de TI
Implementar medidas Desarrollar planes Implementar medidas

Implementación de recuperación de recuperación reducción del riesgo
Desarrollar los procedimientos
Pruebas iniciales
Gestión Revisión y Pruebas Control de

operativa auditoría los cambios
Educación y
concienciación Formación
Aseguramiento
Gestión de las contingencias en TI
Mejora del proceso

Figura 6.3.12. Esquema de las actividades de la gestión de la continuidad de TI

• Mejora del proceso. Identificar y poner en marcha aquellas acciones que

contribuyan a incrementar la eficacia del proceso.
Las actividades de la gestión de la continuidad se representan en el gráfico de la

figura 6.3.12, un clásico de ITIL.
Las salidas principales del proceso son el plan de continuidad; los contratos de servi-
cios externos de continuidad; el plan de recuperación con los procedimientos y
medios de recuperación operativos; la infraestructura de TI preparada para resistir
y recuperarse ante un desastre; el personal de TI perfectamente entrenado; y los
informes de los resultados de las pruebas de continuidad.
Como salidas secundarias del proceso se obtienen las políticas y los requisitos de
continuidad definidos; el plan de proyecto para la implementación de la continui-
dad; las funciones vitales de negocio (VBF); los resultados de la evaluación de los
riesgos, etc.
Determinar el ámbito de la continuidad

El estudio para la continuidad implica considerar la organización de forma com-
pleta definiendo y comunicando la política de continuidad (junto con el compro-
miso de la dirección), seleccionando la aproximación y métodos para la evaluación
de riesgos y el análisis de impacto en el negocio, dedicando recursos y estableciendo
la correspondiente organización de proyecto.
Como resultado de esta actividad se identifica el alcance de la continuidad, es decir,
hasta dónde va a llegar la gestión de la continuidad, es decir, qué servicios y hasta
qué nivel van a estar amparados por la gestión de la continuidad.
El alcance esperado de la gestión de la continuidad debe abarcar a todos y cada uno
de los servicios y toda la información gestionada. La organización de TI no debe
“jugar a los dados” con la información de la empresa y dejar sin cobertura algunos
servicios o información, para que el azar determine su permanencia en caso de una
contingencia, por poco relevantes que sean. Por eso, la cobertura de la gestión de la
continuidad debería comprender absolutamente todos los servicios de TI, los críti-
cos y los no críticos, pero con soluciones técnicas y niveles de recuperación distin-
tos, adecuándolos a los presupuestos disponibles. Poniendo primeramente el foco
en los servicios críticos, para abordar posteriormente los servicios menos críticos.
No hay justificación para dejar excluido nada, pues en el extremo más económico
de las soluciones de continuidad está la cobertura mediante una simple copia de
seguridad completa de sistemas y de los datos, custodiada en instalaciones separadas.
99,99%

Requerimientos y estrategia de la continuidad

Una vez establecido el ámbito y el alcance que se va a dar a la continuidad y lan-
zado el proyecto de implementación, se inicia una etapa en la que el contacto y las
relaciones con todas las áreas de la empresa tiene gran importancia. Su objetivo es
determinar los requisitos y la estrategia que se debe seguir en la implementación.
Lo habitual es que esta actividad se realice dentro del plan general de continuidad
del negocio, en el que TI participaría como un área más.
En esta etapa de requerimientos y estrategia se realiza:
• El análisis del impacto al negocio y la identificación de las funciones vitales
del mismo.
• La evaluación de riesgos, amenazas y contramedidas posibles.
• La definición de la estrategia de continuidad de negocio que se debe ejecutar
y la definición de los requerimientos del negocio que se deben cumplir.
Esta información servirá de entrada al diseño de las soluciones de continuidad.

Dados los altos costes de las soluciones de continuidad de TI y la reducida frecuen-
cia de su utilización, es necesario aquilatar bien los requerimientos, siendo cons-
cientes de que la reducción del tiempo objetivo de recuperación (RTO, Recovery
Time Objective) de horas a minutos puede triplicar el coste de las infraestructuras
necesarias. Por ello, se recomienda realizar un análisis iterativo entre impacto en el
negocio, los riesgos, los requisitos y el coste de las soluciones posibles, para llegar
a un punto de consenso con toda la organización.
El análisis del impacto en el negocio, conocido como BIA (Business Impact Analysis),
permite determinar las pérdidas que puede soportar una organización como conse-
cuencia de la parada de los servicios. También cuantifica la magnitud de las pérdi-
das en función del tiempo que dure la parada de los servicios del negocio. El BIA
debe identificar con claridad:
• Las funciones o procesos críticos del negocio, conocidos como VBF (Vital
Business Functions).
• La magnitud de los daños o pérdidas que puede soportar una empresa como
consecuencia del bloqueo de estos procesos críticos de negocio (umbral de
riesgo de la empresa).
En la figura 6.3.13 se muestra un ejemplo de contenido del análisis del impacto en

el negocio.
Análisis del impacto en el negocio (BIA)
3 Descripción de la actividad principal del negocio.

Áreas principales.
3 Funciones vitales del negocio (VBF).
3 Cuantificación de las pérdidas potenciales:
• Pérdida de ingresos inmediatas y a largo plazo.
• Costes adicionales.
• Pérdida de reputación.
• Pérdida de relaciones comerciales.
• Pérdida de ventaja competitiva.
• Pérdidas por incumplimiento de normativa.
• Pérdida de la capacidad operativa.
3 Evolución de las pérdidas con el tiempo (minutos,
horas, días). Períodos con mayor impacto.
3 Evaluación de los recursos mínimos para continuar
las operaciones de las funciones vitales del negocio.
3 El plazo mínimo en el que se deberían recuperar
los servicios (RTO), en condiciones mínimas y
en operación normal.
3 El período de información perdida que es admisible
por el negocio (RPO).
3 Prioridades del negocio en la recuperación de las
funciones vitales.
Figura 6.3.13. Estructura tipo del BIA
La descripción de las funciones vitales del negocio es una actividad clave, que será
de utilidad para la continuidad, pero también para la disponibilidad y para la segu-
ridad. En la figura 6.3.14 se muestra una ficha de ejemplo para la descripción de
estas funciones de negocio.
La evaluación de riesgos permite identificar la posibilidad de que ocurra un desas-
tre o alguna interrupción grave de los servicios. Ofrece una evaluación de la proba-
bilidad de que ocurra el suceso y la vulnerabilidad o exposición de la organización
99,99%

Funciones vitales de negocio (VBF)

% pérdida
ingresos Rendimiento
Pérdida Tiempo
+10 d
Función Impacto datos parada Valor Valor
Criticidad
2d
5d
2h
1d
de negocio negativo admisible admisible normal mínimo
Denominación,
descripción de
la actividad y
su importancia
para la empresa
RPO RTO
Estimación económica del impacto Valores límite Rendimientos

si fallase la función de negocio admisibles por de la función de
el negocio de pérdida negocio, normal
sin impacto o con y el mínimo
Clasificación en cuanto a la impacto leve admisible
importancia de la función para
la actividad de la empresa
Figura 6.3.14. Ficha ejemplo para la descripción de las VB
al mismo. La metodología de evaluación del riesgo es la misma para la continui-

dad, para la disponibilidad o para la seguridad y, aunque la disciplina es similar, los
conceptos analizados son diferentes: fallo extraordinario de los servicios, fallo coti-
diano de los servicios y fallo en la seguridad. En todos ellos se realiza la:
• Identificación de los riesgos.
• Evaluación de los activos y sus niveles de vulnerabilidad y amenazas.
• Evaluación de los niveles de riesgo.
• Gestión del riesgo: contramedidas, priorización, etc.
En el análisis de los riesgos se puede utilizar la metodología CRAMM 1 centrada en

la identificación de los activos, las amenazas y las vulnerabilidades. Una vez identi-
ficados los riesgos, hay que gestionarlos, identificando las contramedidas justifica-
bles para combatirlos. Para la gestión del riesgo se puede utilizar la metodología
M_o_R (Management of Risk) que estructura la actividad en 5 etapas: políticas,
1
Véase también la Norma ISO/IEC Guide 73. Risk management. Vocabulary. Guidelines for use in
standards.
aproximación, proceso, institucionalizar y revisar, y comunicar. En la figura 6.3.15

se muestran los esquemas de estas dos metodologías.
CRAMM M_o_R
Gestión de riesgos
Activos Amenazas Vulnerabilidades • M_o_R políticas
• M_o_R aproximación:
– Políticas gestión de riesgos
Análisis de riesgos – Guía del proceso
Riesgos – Planes
Gestión de riesgos
– Registros del riesgo
– Gestión de logs
• M_o_R proceso:
Contramedidas – Identificar
– Evaluar
– Planificar
– Implementar
• Institucionalizar y revisar M_o_R
• Comunicar
Figura 6.3.15. Metodologías de evaluación y de gestión de riesgos
La evaluación de los riesgos de contingencia severa en los servicios arroja como

resultados una clasificación en función del nivel de vulnerabilidad de la instalación,
frente a la probabilidad de ocurrencia del suceso (amenaza). En la figura 6.3.16 se
muestra un ejemplo de la tabla de medición de riesgos.
Los requerimientos de continuidad se determinan teniendo en cuenta las necesida-
des del negocio, expresadas en el desarrollo del plan de continuidad del negocio, en
reuniones específicas con el negocio y también en los requisitos de continuidad
contenidos en los SLA en vigor con los clientes.
La estrategia de continuidad de negocio se define a partir del análisis del impacto
en el negocio (BIA) y de la evaluación de los riesgos. La estrategia debe ser el resul-
tado del balance entre las medidas de reducción del riesgo y las soluciones de conti-
nuidad. La estrategia debe priorizar los servicios por orden de recuperación, pero
teniendo en cuenta las posibles variaciones dependiendo del momento en el que se
produzca la contingencia.
99,99%

Evaluación del riesgo
Riesgo = Vulnerabilidad x Amenaza
• Terrorismo • Pandemia virus

Alta
• Terremoto • Rotura tubería en CPD

Vulnerabilidad
Media
• Incendio • Fallo climatización

• Fallo comunicaciones
Baja
• Desbordamiento ríos • Fallo ecléctico exterior

Baja Media Alta
Amenaza
Fuente: Libro ITIL Provisión de Servicio publicado por OGC y e.p.
Figura 6.3.16. Ejemplo de una matriz de evaluación de riesgos
La Norma ISO/IEC 20000-2 establece claramente los requisitos que se deben con-
siderar en la estrategia de continuidad, indicando además que se debe revisar por lo
menos una vez al año, y que los cambios a la misma se deben acordar formalmente.
UNE-ISO/IEC 20000-2
Estrategia de continuidad del servicio siguiente con cada grupo de clientes y

El proveedor del servicio debería des- servicios:
arrollar y mantener una estrategia que a) los períodos máximos aceptables
defina el enfoque general a seguir para de pérdida continuada del servicio;
satisfacer las obligaciones de continui-
b) los períodos máximos aceptables
dad del servicio. Esta estrategia debería
de degradación del servicio;
incluir la evaluación de riesgos y tener en
cuenta los horarios de servicio acorda- c) los niveles aceptables de degrada-
dos y los periodos críticos del negocio. El ción del servicio durante un periodo
proveedor del servicio debería acordar lo de recuperación del servicio.
La estrategia de continuidad debería ser Cualquier cambio a la estrategia debe-

revisada con una periodicidad acor- ría ser acordado formalmente.
dada, al menos anualmente.
En la definición de la estrategia se establecen dos requisitos esenciales para cada

servicio, que servirán de base para determinar las soluciones de continuidad que se
deben establecer:
• RPO (Recovery Point Objective) o el punto objetivo de recuperación, fija el
estado de la información que se recuperará después del desastre, pues siem-
pre habrá algo que se puede perder. El RPO determina la frecuencia de las
copias de seguridad o de las soluciones de replicación remotas de datos.
• RTO (Recovery Time Objective) o el tiempo objetivo de recuperación, esta-
blece el plazo en el que se debería restaurar un servicio. El RTO determina
la arquitectura que se debe seleccionar para la recuperación. Los plazos
de segundos requerirán soluciones activo-activo. En cambio, los plazos de
semanas permitirán soluciones manuales muy económicas.
En la figura 6.3.17 se muestra el esquema típico para explicar el RPO y el RTO.
Figura 6.3.17. Los conceptos de RPO y RTO en continuidad
De cara a la definición de la estrategia, las principales alternativas de recuperación

de los servicios de TI se muestran en la figura 6.3.18. Cuanto más corto es el plazo
99,99%

de recuperación (RTO), más cara es la implantación de la solución para TI, pero

menos pérdidas habrá en el negocio.
Fuente: The Definitive Handbook of BCM y e.p.
Figura 6.3.18. Alternativas de recuperación de los servicios de TI
Siguiendo la clasificación realizada en ITIL, las principales soluciones de continui-

dad que se pueden considerar son:
• Recuperación inmediata. Proporciona una recuperación instantánea (mirro-
ring) sin pérdida de servicios y sin pérdida de información apreciable (RPO y
RTO son iguales a cero). Esta solución se basa en centros de proceso de datos
conectados en activo-activo, es decir, un mismo servicio está ejecutándose de
forma simultánea en ambos centros, con datos sincronizados y balanceando
la carga entre ambos. Las soluciones de procesamiento distribuido entre múl-
tiples servidores y centros de datos (grid computing) son soluciones de alta
resistencia, pero que requieren aplicaciones especialmente adaptadas.
• Recuperación rápida. Conocida como hot standby, está proporcionada por
dos centros de datos conectados y con las aplicaciones cargadas en ambos y
con replicación de datos entre ellos. Una aplicación sólo está ejecutándose en
uno de los centros y, en caso de necesidad, debe activarse en el otro centro
(de respaldo). Proporciona tiempos de recuperación inferiores a 24 horas
(RTO), con una pérdida de datos (RPO) casi nula si se implementa una
replicación del almacenamiento por fibra.
• Recuperación intermedia. Conocida como warm standby, utiliza instalacio-
nes de respaldo proporcionadas por terceros. Los plazos de recuperación
esperados están normalmente entre las 24 y 72 horas.
• Recuperación gradual. Conocida como cold standby, emplea un centro de
respaldo que únicamente contiene la infraestructura física y de conectividad
necesaria. Por lo que, en caso de emergencia, hay que instalar los servidores,
el almacenamiento, las aplicaciones, configurar, etc. Los tiempos de recupe-
ración son superiores a las 72 horas. La información se carga desde la última
copia de seguridad realizada y llevada a resguardo, por lo que la pérdida de
información puede ser superior a las 24 horas (RPO).
• Acuerdos recíprocos. Acuerdos entre empresas u organizaciones para alojar
los servicios en caso de contingencia.
• Soluciones manuales. Soluciones provisionales, como por ejemplo, regis-
trar los tickets de incidentes en el service desk en formularios en papel. Tam-
bién comprenden la restauración de los servicios de forma completa desde
las copias de seguridad.
De acuerdo a los resultados obtenidos en la evaluación de los riesgos, se desarrolla

un plan general para determinar el alcance específico que debe tener la continuidad
del negocio. El plan general de continuidad debe ser aprobado por la dirección.
Este plan general se revisa cada vez que hay un cambio en los procesos clave, insta-
laciones, equipos, personal y servicios contratados que pueda producir nuevas inte-
rrupciones con repercusiones en los servicios prestados.
Implementar la continuidad
Una vez establecida la estrategia de continuidad y los requisitos, se pasa a la elabo-
ración del plan de continuidad de TI y a su implementación. Es necesario que pre-
viamente se haya aprobado el plan general de continuidad del negocio. En la etapa
de implementación se realizan las siguientes actividades (según ITIL):
• Organización y planificación de la implementación, que realiza la elabora-
ción y documentación del plan de continuidad de TI.
99,99%

• Implementación de los acuerdos de recuperación con suministradores de

servicios.
• Desarrollo de los planes de recuperación para cada servicio, infraestructuras, etc.
• Implementación las medidas de reducción del riesgo aprobadas.
• Desarrollo de los procedimientos detallados de actuación.
• Implantación de los procedimientos definidos para la recuperación en los
plazos requeridos.
El plan de continuidad de TI es un documento o estructura documental que

recoge toda la información necesaria para implantar las soluciones de continui-
dad y para posteriormente restaurar los servicios. En la figura 6.3.19 se propone
Plan de continuidad de TI
Introducción Fase de recuperación servicios

3 Objetivo, alcance y dependencia con otros planes. 3 Plan de alojamiento y de servicios.
3 Políticas. 3 Plan de redes y sistemas informáticos.
3 Resumen del análisis impacto en negocio (BIA). 3 Plan de telecomunicaciones.
3 Funciones vitales (VBF), niveles de servicio 3 Plan de seguridad.
continuidad, RPO y RTO. 3 Plan de personal.
3 Resumen de la evaluación de riesgos. 3 Plan de administración y finanzas.
3 Descripción de la estrategia de continuidad en TI. 3 Relación de manuales y guías técnicas y otros
Organización y recursos documentos necesarios para la recuperación.
3 Organización: ejecutiva, de coordinación y de Fase de vuelta a la normalidad
recuperación. 3 Plan de retorno a la normalidad.
3 Infraestructuras específicas para recuperación.
Plan de pruebas
3 Servicios externos contratados.
Anexos:
Fase de invocación
3 Datos de contacto de personal y suministradores.
3 Plan de respuesta a emergencias (procedimientos
notificación). 3 Descripción de los centros alternativos de respaldo.
3 Plan de evaluación de daños. 3 Inventario de infraestructuras.
3 Personas que pueden declarar una emergencia y, 3 Acuerdos de nivel de servicio con suministradores.
consecuentemente, activar el plan. 3 Procedimientos de los equipos de emergencia.
3 Criterios para la activación del plan de continuidad. 3 Manuales y guías técnicas.
3 Procedimientos de comunicación, los equipos de 3 Planes de comunicación y programas de formación
emergencia y los suministradores involucrados. del plan.
3 Análisis impacto en negocio (BIA).
Fase de transición
3 Relación de servicios y recursos.
3 Secuencia acciones previas a la recuperación de los
recursos: traslados, adquisiciones, etc. 3 Relación de eventos.
3 Plan de salvamento. 3 Alternativas de respaldo (coste, tiempo de activación
y cobertura).
3 Plan de registros vitales.
3 Plan de gestión de la crisis y de relaciones públicas.
3 Otros procedimientos fase transición.
Fuente: Libro ITIL Diseño del Servicio publicado por OGC y Telefónica.
Figura 6.3.19. Estructura ejemplo de un plan de continuidad de TI

esquema del plan articulado en torno al ciclo de vida de la gestión de una con-
tingencia.
En relación al plan de continuidad, las Normas ISO/IEC 20000 recomiendan una
política formal de registro de la documentación relacionada, la salvaguardia de los
datos de configuración y, especialmente, de la información necesaria para la restau-
ración de los servicios: plan de continuidad, procedimientos, etc.
UNE-ISO/IEC 20000-1
Los planes de continuidad del servicio, la lista de contactos y la base de datos de

gestión de la configuración deben estar disponibles incluso en el caso de que no sea
posible el acceso normal a las oficinas. El plan de continuidad del servicio debe
incluir la actividad de vuelta a la normalidad.
UNE-ISO/IEC 20000-2
6.3.4 Planificación y prueba de la

continuidad del servicio d) las copias de seguridad de los
datos, los documentos, el soft-
El proveedor del servicio debería asegu-
ware y cualquier equipo y perso-
rar que:
nal necesario para la restauración
a) los planes de continuidad tienen del servicio están disponibles de
en cuenta las dependencias entre forma rápida ante un desastre o
el servicio y los componentes de un fallo importante del servicio;
los sistemas;
e) al menos una copia de todos los
b) se registran y mantienen los pla- documentos relativos a la conti-
nes de continuidad del servicio y nuidad del servicio debería estar
el resto de documentos requeri- almacenada y ser mantenida en
dos para dar soporte a la conti- una localización remota y segura,
nuidad del servicio; junto al equipamiento que sea
necesario para permitir su uso;
c) la responsabilidad para activar los
planes de continuidad está clara- f) el personal conoce y asume su rol
mente asignada y los planes esta- para activar y/o ejecutar los pla-
blecen claramente la responsabili- nes y tiene acceso a la documen-
dad para la toma de las acciones tación relativa a la continuidad
necesarias frente a cada objetivo; del servicio.
99,99%

Como detalle del plan de continuidad se suele generar un plan de recuperación,

como documento independiente, pues al contener los detalles de las personas de
contacto, procedimientos e instrucciones operativas, su revisión y actualización
es muy frecuente. En la figura 6.3.20 se muestra un contenido tipo del un plan de
recuperación.
Plan de recuperación
3 Estrategia de recuperación.
3 Procedimiento de invocación.
3 Interfaces y dependencias con otros planes.
3 Directrices generales.
3 Dependencias: sistemas, infraestructuras, servicios
externos, etc.
3 Lista de contactos: personal TI, personal otras áreas,
dirección, suministradores.
3 Grupo de recuperación: de TI, de servicios
generales, etc.
3 Lista de comprobación del grupo de recuperación.
3 Formulario de evaluación de daños.
3 Procedimientos de recuperación:
• Recuperación del service desk.
• Recuperación telecomunicaciones.
• Recuperación de la LAN .
• Recuperación de la WAN.
• Recuperación servidores y almacenamiento.
• Recuperación de datos.
• Recuperación de PC.
• Recuperación alimentación eléctrica.
• Recuperación aire acondicionado.
• Comunicación in situ, etc.
Fuente: Libros ITIL Diseño del Servicio y A Guide to Business Continuity Plan publicados por OGC.
Figura 6.3.20. Contenido tipo de un plan de recuperación ante un desastre

Gestión operativa de la continuidad

La gestión operativa de la continuidad se centra en mantener actualizados el plan
de continuidad, toda la información asociada y a toda la organización concienciada
y perfectamente entrenada, además de la ejecución del plan de pruebas correspon-
dientes. Las actividades que comprende son:
• Educación y concienciación de toda la organización y, especialmente, en TI.
• Revisión y auditoria de los planes y las soluciones: periódicamente, después
de pruebas o después de cambios importantes.
• Pruebas y simulacros de los planes para comprobar su funcionamiento y
entrenar al equipo humano. Detección de acciones de mejora.
• Control de los cambios, con el fin de que las soluciones de continuidad estén
siempre vigentes y la información actualizada.
• Formación y entrenamiento específico del personal que deba actuar en las
contingencias.
• Aseguramiento o inculcación de la confianza necesaria en la dirección de que
el plan de continuidad de TI ofrecerá los resultados esperados y definidos en
los requerimientos.
• Gestión de las contingencias en TI. Activación del plan de continuidad en el
caso de que ocurra una contingencia severa.
Una vez elaborado el plan de continuidad, debe ser difundido y puesto a disposi-
ción de las partes involucradas. El responsable del plan de continuidad de TI debe
formar al personal a su cargo sobre las actuaciones que se deberán realizar en el
caso de que se produzca cualquiera de las situaciones identificadas como de emer-
gencia o desastre.
El responsable del plan establece anualmente un plan de pruebas, donde se definen
las pruebas que se deben llevar a cabo para asegurar la actualización y eficacia de
todos los planes de continuidad de la organización.
UNE-ISO/IEC 20000-1
El plan de continuidad del servicio debe probarse de acuerdo a las necesidades del
negocio.
Todas las pruebas de continuidad se deben registrar y tras las pruebas fallidas se
deben elaborar planes de acción.
99,99%

UNE-ISO/IEC 20000-2
Los planes de continuidad del servicio y Se deberían llevar a cabo pruebas con
la documentación relacionada (por una frecuencia suficiente para asegu-
ejemplo los contratos) deberían estar rar que los planes de continuidad son
ligados a los procesos de gestión del efectivos y permanecen así aún cuando
cambio y de gestión de los contratos. se producen cambios en los sistemas,
Los planes de continuidad del servicio y procesos, personal y necesidades del
la documentación relacionada (por negocio. El cliente y el proveedor del
ejemplo los contratos) deberían eva- servicio deberían estar implicados con-
luarse respecto al impacto previamente juntamente en las pruebas, basadas en
a que se aprueben los cambios en el un conjunto acordado de objetivos.
sistema y en el servicio, y previamente a Los fallos en las pruebas se deberían
acordar los nuevos requisitos del cliente documentar y revisar para proveer de
o bien cambios en éstos siempre que información a un plan de mejora del
sean significativos. servicio.
Una vez aprobado el plan de pruebas, que debe ser respaldado por la dirección, se
realizan acciones de comunicación entre los responsables de los procesos y servicios
implicados, para que estén al tanto de los planes establecidos.
Cada vez que se realice una prueba, el responsable de realizarla dejará constancia
del resultado en el informe de pruebas, que describe las acciones llevadas a cabo y
la eficacia del plan de continuidad. Esta información la analiza el responsable del
proceso, que revisa periódicamente la eficacia de los planes para proponer las mejo-
ras que crea necesarias.
Asimismo, el responsable del proceso es el encargado de que los planes de conti-
nuidad se mantengan actualizados y acordes a la situación actual de la organización.
Para ello, periódicamente debe analizar los cambios realizados que pudieran afectar
al plan, como por ejemplo los:
• Cambios en los procesos (existentes, nuevos o suspendidos).
• Cambios en la estrategia de negocio.
• Cambios en los SLA.
• Cambios en los acuerdos o contratos con proveedores.
• Cambios en la legislación.
• Una nueva evaluación de riesgos.
• Cambios en las ubicaciones, dispositivos y recursos.
• Cambios en el personal.
• Cambios de direcciones, números de teléfono o información de contacto.
En caso de modificación del plan de continuidad de TI, el responsable del proceso,

emite una nueva revisión del plan, identificando el motivo del cambio, el número
de versión del documento y la fecha del cambio para su posterior aprobación. Asi-
mismo, se actualizará el plan general de continuidad del negocio si fuera necesario.
Mejora del proceso de continuidad

Al igual que se ha detallado para la disponibilidad, en la gestión de la continuidad
es recomendable identificar áreas de mejora. Las mejoras pueden proponerse desde
el propio proceso, identificarse por el resultado de las pruebas o definirse tras una
situación de contingencia. El resto de los procesos proporcionan información que
puede contribuir a mejorar la continuidad. También se deben tener en cuenta los
cambios que vayan ocurriendo, como por ejemplo, nuevos SLA, variaciones en los
resultados de la evaluación de riesgos en seguridad o disponibilidad, cambios en la
infraestructura, etc.
Las mejoras a la continuidad, al igual que en la disponibilidad, una vez aprobadas,
se gestionan en el plan de mejora unificado (véase el capítulo 4).
Métricas del proceso (disponibilidad y continuidad)

Al ser la disponibilidad el centro sobre el que giran todos los servicios, las métricas
de la gestión de la disponibilidad tienen mucha importancia para el seguimiento
diario, semanal, mensual y anual, de los servicios de TI. Las más destacadas son:
• Porcentaje de disponibilidad de los servicios. Es sin lugar a duda, la
métrica por excelencia en TI. La vorágine de métricas no debe hacer perder
el foco en este “rey de reyes” de los indicadores de TI, que siempre se debe
medir y seguir.
• Porcentaje de disponibilidad de los servicios críticos, con un detalle espe-
cífico para cada una de las funciones vitales del negocio.
• El tiempo de respuesta de los servicios es otro de los grandes indicadores
de TI, pues indica si son utilizables. Influye directamente en la productivi-
dad de la empresa. Se debe detallar el tiempo de respuesta según la criticidad
de los servicios.
99,99%

• Porcentaje de disponibilidad total de los servicios prestados por suministra-

dores.
• MTBSI (Mean Time Between Systems Incidents), frecuencia media con la que
se producen los incidentes.
• MTTR (Mean Time To Repair, “downtime”, Mean Time To Restore), tiempo
medio de restauración de los servicios tras incidentes.
• Número de fallos o incidentes repetidos.
• Costes asociados al proceso.
• Porcentaje de no disponibilidad de los servicios por paradas planificadas.
• Porcentaje de servicios con niveles de disponibilidad acordes a los SLA.
• Porcentaje de disponibilidad de los componentes de los servicios.
• Aumento del porcentaje de la fiabilidad de servicios y componentes.
• Porcentaje de roturas de SLA, OLA y contratos con terceros revisados.
• Mejora del porcentaje en disponibilidad global extremo a extremos de los
servicios.
• Porcentaje de reducción en el número e impacto de las paradas (manteni-
mientos) en el servicio.
En la figura 6.3.21 se muestra el modelo abreviado de métricas de itSMF España

para la disponibilidad.
Las métricas de la gestión de la continuidad son mucho menos relevantes que las
relativas a la disponibilidad. Están centradas en informar sobre los grados de cober-
tura, resultados de las pruebas, de las auditorias, etc. Las principales métricas de la
gestión de la continuidad son:
• Porcentaje de servicios cubiertos por el plan de continuidad de TI.
• Retraso en la actualización del plan de continuidad.
• Número de fallos en las pruebas de los planes de continuidad.
• Costes asociados al proceso.
• Retrasos en las fechas de las pruebas planificadas.
• Porcentaje de servicios recuperados en tiempo en las pruebas del plan.
• Pérdida de ingresos estimada según los resultados de las pruebas.
Métricas principales de la gestión de la disponibilidad
Figura 6.3.21. Métricas de la gestión de la disponibilidad
• Resultados de la encuesta de conocimiento del plan de continuidad.

• Número de cambios generados para subsanar los fallos en las pruebas.
• Tiempo total dedicado a las pruebas del plan.
• Porcentaje de personal que ha recibido formación sobre las actividades de
recuperación.
En la figura 6.3.22 se muestran las métricas recomendadas en el modelo abreviado

de métricas de itSMF España.
Roles participantes en la gestión de la disponibilidad y

la continuidad
Al igual que en la generación de informes, la disponibilidad y la continuidad tienen
una etapa de definición e implementación y otra de gestión operativa. La etapa de
implementación se suele contratar externamente con un enfoque orientado a pro-
yecto llave en mano (especialmente en el caso de continuidad), mientras que en la
etapa de gestión operativa se realizan las pequeñas tareas del día a día que mantie-
nen activos y vigentes los planes. Sobre estas dos facetas tan distintas actúa un rol
99,99%

Métricas principales de la gestión de la continuidad
Figura 6.3.22. Métricas principales de la gestión de la continuidad
responsable que, primero controla el proyecto de definición e implementación del

plan, para después gestionar la operativa del día a día.
La responsabilidad del proceso puede recaer en una sola persona o puede dividirse
en dos, asignando a uno la disponibilidad y a otro la continuidad. Dependerá de
las dimensiones de la organización y los servicios que preste. Las tareas relaciona-
das con la continuidad aparecen con frecuencia vinculadas al área de seguridad, por
lo que la titularidad del proceso puede ser desempeñada conjuntamente.
Los principales roles del proceso son:
• El gestor de la disponibilidad. Se responsabiliza de la definición, implanta-
ción y control de la disponibilidad. Es también el responsable de la mejora
continua del proceso. Trabaja en función de los objetivos generales acorda-
dos con el responsable de los servicios de TI.
• El gestor de la continuidad. Es el encargado de definir, desarrollar e imple-
mentar el plan de continuidad de los servicios de TI para cumplir en todo
momento los objetivos de recuperación del negocio. Gestiona la mejora con-
tinua del proceso y se coordina con el responsable de la gestión de servicios
de TI. También es el responsable de:
– Mantener y ejecutar el plan de pruebas.
– Realizar revisiones periódicas de la calidad de todos los procedimientos

para asegurar su inclusión en el plan de pruebas.
– Realizar revisiones regulares, al menos anualmente, de los planes de con-
tingencia con las áreas del negocio para asegurarse de que reflejan con
exactitud la realidad.
• En lo relativo a la etapa del proyecto de implantación se puede contar con

un jefe de proyecto que asista al gestor.
• Arquitecto tecnológico. Realiza la definición de la arquitectura tecnológica
para que los sistemas sean capaces de alcanzar la disponibilidad demandada.
También diseña las plataformas para la continuidad de los servicios. Las prin-
cipales disciplinas de su ámbito son: el balanceo de carga, la consolidación,
la virtualización y la replicación remota. Una vez definidas las arquitecturas,
se informa de su rendimiento y se mantiene al día del avance tecnológico con
el fin de proponer mejoras al mismo.
• Especialistas de soporte. Son técnicos especializados que se encargan de la
monitorización de los elementos de infraestructura de TI, participan en las
pruebas de la continuidad, etc.
• Administrador y soporte de disponibilidad. Es el responsable de la adminis-
tración a nivel técnico (de sistemas y de herramientas) del proceso de ges-
tión de disponibilidad. Se ocupa de proporcionar y mantener los medios téc-
nicos necesarios para una gestión eficiente del proceso.
• Administrador y soporte de continuidad. Apoya al gestor de la continuidad
en sus funciones.

• El responsable del plan de continuidad del negocio, con el que tiene que
enganchar el plan de continuidad de TI.
cumplan los niveles pactados. Aporta la relación con la dirección de la
empresa y las principales directrices para la disponibilidad y continuidad.
Proporcionan los presupuestos para los costosos planes de implementación.
Revisa y valida las alternativas de diseño y los resultados finales.
• El responsable de las relaciones con el negocio lleva el contacto con el negocio
para el análisis de impacto (BIA), la identificación de las funciones vitales, en la
definición de los requerimientos del negocio y en la gestión de todo contacto,
participación o validación que se requiera por parte de las áreas cliente de TI.
99,99%

• El gestor financiero debe dotar de recursos para la implementación de las

arquitecturas y soluciones definidas. Debe además balancear entre los presu-
puestos disponibles y las soluciones que se desean alcanzar.
• El gestor de cambios debe identificar los cambios que tienen impacto en la
disponibilidad y en la continuidad, para que sean validados por este proceso.
• El propietario del modelo SGSTI actúa como propietario del proceso (process
owner), define el proceso, vela por el cumplimiento y actividades del proceso, y
se encarga de la mejora continua del mismo.
En la figura 6.3.23 se muestran los principales roles del proceso:
Roles del proceso
Responsable de la
Gestor continuidad TI
Gestor
disponibilidad
Responsable plan
de continuidad negocio
Gestores de otros
procesos y áreas TI Arquitecto tecnológico Especialista
de soporte
SGSTI
Propietario del Administrador y Administrador y

modelo (SGSTI) soporte disponibilidad soporte continuidad
Figura 6.3.23. Roles de gestión de la disponibilidad y continuidad

Resumen
La gestión de la disponibilidad y de la continuidad parte de principios muy simila-
res de alineación con las necesidades del negocio y de creación de planes, para poste-
riormente divergir en dos disciplinas diferenciadas. La primera es la disponibilidad
que se convertirá en el astro rey de los servicios. El porcentaje de disponibilidad será
la obsesión de todo responsable. La segunda, la gestión de la continuidad, “juega a
los dados” con el azar y el futuro de la empresa, proponiendo a la dirección impor-
tantes inversiones para garantizar la supervivencia, e intentando sustraer presu-
puesto de las actividades operativas.
Una vez implantados los planes, la gestión de la disponibilidad estará continua-
mente en boca de todos, mientras que la gestión de la continuidad se convertirá en
ese profeta que muchas veces predica en el desierto.
La gestión de la disponibilidad tiene por objeto que se alcancen las máximas cotas
de disponibilidad posibles (dentro de las requeridas por el negocio), o por lo menos,
los niveles pactados siempre moviéndose dentro del ámbito presupuestario asig-
nado. La gestión de la disponibilidad trabaja para alcanzar los siguientes resultados:
• Tasas de disponibilidad y tiempos de respuesta acordes con lo pactado con el
negocio y, al menos, que sean similares a las de las empresas de la competencia.
• Definición de las directrices de diseño para la disponibilidad. Diseño de
arquitecturas de disponibilidad.
• Tipificación de los servicios en función de su criticidad para el negocio.
• Generación y revisión del plan de disponibilidad.
• Planificación y control de componentes de la infraestructura y de los servi-
cios, para asegurar el cumplimiento de las necesidades de disponibilidad
actuales y futuras.
• Análisis de las situaciones de no disponibilidad del servicio, con el fin de
identificar mejoras. Interviene a posteriori, después de que la gestión del
incidente haya restaurado el servicio.
• Mejorar la disponibilidad de la infraestructura.
• Controlar que los cambios cumplen con unos niveles de disponibilidad ade-
cuados y fiables.
La gestión de la disponibilidad y la continuidad deben estar presentes desde

el momento en que se decide crear un servicio. Para ello, es necesaria una perfecta
sintonía tanto con gestión de nivel de servicio, como con el proceso de creación de
nuevos servicios o modificación de los existentes.
99,99%

La gestión de la continuidad de TI se centra en garantizar que, después de una con-

tingencia severa, la empresa seguirá teniendo los servicios que necesita en el plazo
acordado. Proporciona los siguientes resultados:
• Identificación de los riesgos que la organización está afrontando, en térmi-
nos de probabilidad e impacto. La identificación y priorización de los proce-
sos clave de la organización.
• Evaluación del impacto que tendrían las interrupciones en el negocio y fijar
los objetivos del negocio en lo referente a los recursos de TI.
• Formulación de la estrategia de continuidad de negocio coherente con los
objetivos y prioridades de negocio.
• Realización del plan de continuidad de TI, junto con todos los procedimien-
tos o planes de recuperación asociados.
• Contratación de pólizas de seguros adecuadas para mitigar la exposición a
pérdidas económicas.
• Implantación de las contramedidas de reducción del riesgo y de las solucio-
nes de continuidad.
• Personal concienciado y entrenado para actuar en el caso de un desastre.
Beneficios
Los principales beneficios son la obtención de una correcta disponibilidad y tiempo
de respuesta de los servicios, y una mejora significativa en la garantía de continui-
dad de los servicio de TI.
En cuanto a la gestión de la disponibilidad, los beneficios se resumen en:
• El negocio utiliza unos servicios con unos niveles de disponibilidad y tiempo
de respuesta adecuados a sus necesidades.
• Los servicios se diseñan sobre una arquitectura planificada para ofrecer la
disponibilidad deseada.
• Los cambios se prueban para verificar el cumplimiento de los criterios de
disponibilidad.
• Se identifican los incumplimientos y se investiga su causa.
• Los niveles de disponibilidad se monitorizan continuamente y se mejoran
donde sea necesario.
• Se detecta la incapacidad de determinados suministradores para satisfacer los

requisitos de servicio.
• Se salvan fallos evitables en los servicios.
Los beneficios aportados por la gestión de la continuidad son:

• Se conocen y se tienen acordados, con el negocio, las necesidades de conti-
nuidad de los servicios de T, en función de las necesidades de continuidad de
las funciones del negocio.
• Se dispone de un plan de continuidad de TI que aglutina todo lo necesario
para definir, implantar y actuar.
• Se analizan las situaciones que pueden poner en peligro la continuidad de los
servicios, para identificar acciones que controlen esos riesgos, así como, para
identificar acciones de mejora. Se gestionan los riesgos para que la organiza-
ción pueda seguir funcionando, al menos, al nivel mínimo predeterminado.
• Se reduce el riesgo a un nivel aceptable y se planifica la recuperación de los
servicios de TI. Por tanto, se puede esperar una reducción de la prima de
seguros, una mejora de la imagen de la empresa, etc.
• Las soluciones de replicación remota, consolidación y virtualización, que
muchas veces son necesarias, aportan mejoras en la robustez de las infraes-
tructuras y ahorros en la gestión de una planta más uniforme.
• ¿Cuáles son los principales riesgos a los que están expuestos los servi-
cios de TI en su organización¿
• ¿Cuáles son las funciones vitales en su negocio?
• ¿Qué impacto tendría en su negocio una parada de una hora de los
servicios de TI más críticos (bien por fallo interno o por desastre)?
2
6.4. Gestión financiera de TI 331
6.4. Elaboración del presupuesto y contabilidad de

los servicios de TI (gestión financiera de TI)
Figura 6.4.1. Actividades principales del proceso de gestión financiera de TI
La reducción de los costes de TI lleva siendo, en los últimos años, una de las prin-
cipales prioridades de la dirección de sistemas de información. El reto está en con-
jugar esta progresiva constricción presupuestaria con la presencia cada vez mayor
de las tecnologías de la información en el negocio. En tiempos de crisis económica,
el proceso de gestión financiera de TI aporta elementos esenciales de decisión y de
control (véase la figura 6.4.1).
En sentido contrario a la reducción de costes, ha ido creciendo el número de servi-
cios de TI considerados críticos por el negocio. Con la apertura a Internet el
número de usuarios se ha disparado y la demanda de nuevas tecnologías en la
empresa se incrementa cada día.
Además, los antiguamente “iletrados” usuarios de los sistemas son hoy ciudadanos
de un mundo cada vez más digitalizado, que exigen a la empresa el mismo nivel
tecnológico que ellos reciben en su vida privada: un correo con la calidad y capaci-
dad de gmail, entornos colaborativos como los de Internet, un espacio en disco de
red equivalente a su disco USB de bolsillo, etc. Para colmo de males, estos servicios
son gratuitos o a un coste unas cien veces inferior a los que la empresa puede ofre-
cer a sus usuarios.
Todo ello, genera la sensación de que los servicios que TI ofrece al negocio son
inflexibles y caros, provocando una percepción muy negativa en la alta dirección y
en las áreas cliente de TI.
Por fortuna, hay algunos apuntes en el “haber” de TI para equilibrar un poco
la balanza, como por ejemplo las grandes holguras presupuestarias del pasado, la
capacidad actual para poner el foco en lo verdaderamente esencial para la empresa
y el aumento de prestaciones del equipamiento hardware y las nuevas formas de
gestión de TI más eficientes, como las definidas en ISO/IEC 20000 o en ITIL.
La adopción de las mejores prácticas en la gestión económica o financiera de TI y
otras medidas de eficiencia y calidad, aportarán una solución a este callejón sin
salida de hacer más con menos presupuesto. Estas prácticas proporcionan instru-
mentos para responder a los retos de reducción de costes en un entorno de negocio
cada vez más exigente e impulsa a las organizaciones de TI hacia una gestión efi-
ciente de los recursos. Aunque en realidad, la gestión financiera no permite por sí
sola la reducción de costes o el “hacer más con menos”, necesita la existencia del
resto de procesos.
Una gestión económica avanzada de los servicios de TI está caracterizada por:
• La definición de unas políticas de gestión económica o financiera de TI.
• La elaboración precisa y formal de los presupuestos anuales y el seguimiento
con rigor de su evolución.
• La realización de una contabilidad analítica de los costes, que permite el
conocimiento al detalle de los costes de TI en la provisión de los servicios.
• La imputación de costes a las áreas cliente mediante una facturación acorde
con los servicios ofrecidos, para contrapesar la demanda con los costes reales.
Hay que señalar que esta actividad no está dentro del ámbito de la Normas
ISO/IEC 20000, si bien es una actividad muy recomendable y, por ello, tra-
tada en este libro.
Aunque las tecnologías de la información son importantes y estratégicas para la

empresa, el departamento interno de sistemas de información suele ser un centro
de costes, es decir, no genera ingresos. El negocio y el departamento financiero de
la empresa consideran a TI como una unidad interna más, al igual que marketing,
servicios generales, recursos humanos, vigilancia física, etc. Además, el ámbito con-
table-financiero no es una especialidad de TI. Por ello, hay que hacer una aproxi-
mación a la gestión financiera de TI con mucha humildad, reconociendo que se
está ante una actividad que es la especialidad de otro departamento y ante el que TI
es uno más.
Por todo lo anterior, el enfoque de este proceso debe ser algo diferente al resto de
los procesos de TI. Muchas de las descripciones realizadas en este proceso son más
bien explicaciones simplificadas de las disciplinas económicas y van destinadas al
personal de TI para que realice adecuadamente la parte que les corresponde en la
gestión financiera. En este proceso no se pretende dar ningún tipo de lección a los
profesionales de las finanzas.
El proceso de gestión financiera de TI debería conseguir que las necesidades y requisi-
tos particulares de TI se incorporen en los sistemas financieros y contables de la
empresa. Desde la estructura de los presupuestos hasta la contabilización de la última
factura, se deberían realizar integrados en estos sistemas. Es frecuente y lógico que las
organizaciones grandes de TI tengan un grupo propio de personas dedicadas al control
y a la gestión financiera. Pero se debe evitar la tendencia natural de crear un sistema de
control y de gestión de costes de TI paralelo y conseguir que las necesidades puedan
ser cubiertas por el sistema financiero corporativo, aunque en muchos casos, las nece-
sidades particulares de TI (sobre todo desde la perspectiva de gestión de activos y en la
utilización de recursos) requieren la utilización de sistemas complementarios.
En ISO/IEC 20000-2, la gestión financiera de TI se describe en torno a tres áreas:
la definición de las políticas, la elaboración del presupuesto y la contabilidad de los
servicios. Además, en este libro se incorporan también muchas de las recomenda-
ciones de ITIL v2, entre otras, la facturación de los servicios, esencial para equili-
brar la balanza entre la demanda de las áreas cliente y de la oferta de TI. En la
figura 6.4.2 se muestra una introducción a este proceso.
El objetivo principal del proceso es conseguir una administración eficiente de los
recursos económicos de TI. Genera como principales contribuciones:
• La administración eficiente de los activos de TI utilizados para proveer los
servicios de TI.
• Una integración y diálogo perfecto con el área financiera de la empresa.
• El poder realizar una contabilidad exacta de los servicios de TI.
• Facilitar la toma de decisiones sobre inversiones en TI de una forma efi-
ciente.
• Orientar las organizaciones de TI a estructuras de costes más competitivas.
• La optimización de los costes de los servicios de TI. La detección de inefi-
ciencias en costes, permitiendo concentrar los recursos económicos en fun-
ciones esenciales para el negocio.
Proceso de gestión financiera Qué aporta:

de TI • Define las directrices para la gestión
económica de TI.
• Integración con el área financiera de
Definición: la empresa.
Proceso centrado en la gestión • Aumento del rigor en la definición y
económica de los servicios TI, que gestión de los presupuestos.
realiza una administración cuidadosa, • Proporciona una información precisa
responsable y eficiente de los costes. sobre los costes, para la toma de
decisiones sobre inversiones en TI.
• Conocimiento exacto de los costes
Objetivo: totales de propiedad (TCO) a lo largo
Presupuestar y contabilizar los costes de la vida de los servicios.
de la provisión del servicio. • Identifica ineficiencias existentes en
relación a los costes.
Además, en el libro se incluye la
facturación de los servicios. • Permite un uso más eficiente de
los recursos y los servicios de TI,
moderando la demanda de los clientes.
Figura 6.4.2. Introducción al proceso de gestión financiera de TI
• La repercusión de costes indirectos y la asignación de costes directos a servi-

cios, bien a los clientes internos de la organización, o bien a los clientes fina-
les en el caso de proveedores de servicios de TI.
• La racionalización de la demanda de peticiones de servicios en función de su
coste y aportación al negocio, con el resultado de un consumo eficiente de los
servicios por los usuarios.
Este proceso estructura su ámbito en torno a las siguientes áreas:

• Políticas. Directrices que determinan la forma de alcanzar los objetivos.
• Presupuestar. Su finalidad es predecir el gasto económico, conseguir los
recursos necesarios y controlar el cumplimiento del presupuesto de la orga-
nización de TI. Genera un ciclo de negociaciones periódicas que permite
confeccionar los presupuestos (habitualmente anuales), para realizar poste-
riormente el seguimiento semanal o mensual de su ejecución.
• Contabilizar. La contabilidad analítica de costes permite conocer en detalle la
distribución del coste en la cadena de valor de TI. Esta actividad pone énfasis
en la identificación y conocimiento de los costes por servicio y por cliente.
• Facturar. Este punto, no cubierto en las Normas ISO/IEC 20000, agrupa el

conjunto de actividades necesarias para gestionar el cobro a los clientes por
los servicios prestados. Gracias a la contabilidad realizada se puede establecer
una tarifa de precios por cada servicio y sus opciones. Aunque una organiza-
ción determine no facturar a sus clientes, es clave que el cliente conozca de
forma oficial los costes reales de los servicios de TI que demanda y recibe.
A diferencia de los presupuestos, la contabilidad detallada y la facturación son áreas

que no se suelen percibir como prioritarias en TI. Aunque en una certificación
ISO/IEC 20000, los presupuestos y la contabilidad serán requisitos necesarios.
El gestor de este proceso se enfrenta a un entorno técnico, en el que la cultura de la
gestión financiera en TI no es apreciada, ni está extendida. En la figura 6.4.3 se
muestran los principios directores que se deben tener en cuenta en la implementa-
ción de este proceso.
Figura 6.4.3. Principios directores que deben regir el proceso
El primer principio es la integración con la empresa. Este proceso de gestión

financiera pretende que el área de TI se comporte económicamente y en sus deci-
siones como si fuera una compañía. Por esto, su implementación debe estar com-
pletamente integrada con las formas de hacer del resto de la empresa en todos sus
ámbitos: en los presupuestos, en la contabilidad y en la facturación. De esta

forma, TI podrá aprovechar el conocimiento y las herramientas ya en uso en el
resto de la organización para no crear una isla aparte reinventando la forma de
gestionarse económicamente.
Otro de los aspectos clave que contribuyen al éxito de este proceso es el estableci-
miento de los presupuestos de forma negociada con todas las partes implicadas,
tanto con las áreas cliente como con los grupos internos que forman TI. Si el res-
ponsable de un grupo no se siente identificado con el presupuesto y éste no se
ajusta a la realidad, en muy poco tiempo se producirán desviaciones con las consi-
guientes peticiones de ampliación presupuestaria.
La sencillez, que proporciona claridad, es quizá uno de los puntos más difíciles de
conseguir y debe ser un principio básico para todas las actividades que rodean a
este proceso. La sencillez debe estar presente en la elaboración del presupuesto y
sus partidas, en la definición del modelo de costes utilizado, en la contabilización
y en la asignación de precios a los servicios.
La implantación de la normativa legal financiera en las empresas la suele liderar el
departamento financiero, quedando este proceso a sus órdenes para ejecutar los
requerimientos correspondientes al ámbito de TI.
Las empresas multinacionales están sujetas además al cumplimiento de normativas
específicas en el ámbito financiero, entre ellas destaca la relativamente reciente
Sarbanes-Oxley, conocida como “SOX”, que es una ley federal del Gobierno de
Estados Unidos para controlar la gestión financiera de las grandes empresas. Esta
ley americana toma el nombre del senador Paul Sarbanes (demócrata) y el congre-
sista Michael G. Oxley (republicano). Se publicó el 30 de julio de 2002 como
respuesta a los grandes escándalos 1 que hicieron caer la confianza de la opinión
pública en los sistemas de contabilidad y auditoría. Establece nuevos requerimientos
para los consejos de administración y dirección, fija mecanismos contables para
todas las empresas que cotizan en las Bolsas de Estados Unidos, introduce respon-
sabilidades penales en el consejo de administración y establece unos requerimientos
por parte de la SEC (Securities and Exchange Commission), la comisión reguladora
del mercado de valores de Estados Unidos. Los partidarios de esta ley afirman que
la legislación era necesaria y útil, mientras los críticos creen que causará más daño
económico del que previene 2.
1
Enron, Tyco International, Adelphia, Peregrine Systems y WorldCom.
2
La información sobre SOX se ha obtenido de Wikipedia.
Requerimientos
financieros del
negocio para TI
Objetivos financieros Planificación de TI

para TI Cartera de proyectos
y actividades de TI
PRESUPUESTO CONTABILIDAD
Política de gestión SGSTI

financiera de TI Modelo de gestión TI

Gestión del cambio
Modelo
Proceso Procesos
de costes
Mejoras
FACTURACIÓN
PDCA
Modelo de SGSTI
facturación
Precios
Catálogo
de servicios
Figura 6.4.4. Componentes principales del proceso de gestión financiera de TI
Catálogo de servicios. Proporciona una visión sencilla, en terminología entendi-

ble por el negocio, de todos los servicios provistos por TI y las alternativas u opcio-
nes de prestación. El catálogo debería contener los precios.
Contabilizar. Registro detallado de los costes en los que incurre TI, con una visión
de los costes por cada servicio y sus componentes.
Coste. El coste es todo importe económico que debe pagar la organización. El
coste se divide en inversión y en coste operativo.
Coste de capital (CAPEX, Capital Expenditure) o Inversión. Término que
recoge los importes económicos dedicados a incrementar los activos amortizables.
Coste operativo (OPEX, Operating Expenses). Se aplica al coste dedicado a
soportar la actividad (operación y control).
Depreciación o amortización de activos. Es la imputación contable en varios
años de la inversión de capital. El valor de compra del activo se distribuye entre los
años del período de amortización. En la contabilidad de un año no se imputa el

coste total de los activos, sino que sólo se contabiliza la pérdida de valor o depre-
ciación del activo durante el ejercicio. El período de amortización fija el plazo en
que el activo deja de tener valor contable (el valor de adquisición menos el valor
amortizado se iguala con el valor residual del activo). Cada tipo de activo (hard-
ware, software, etc.) tiene un período de amortización regulado legalmente en cada
país (los coeficientes máximos y mínimos están fijados en España por el Ministerio
de Hacienda), que suele oscilar entre los 3 y 5 años.
Elemento de coste. Es todo elemento de configuración o componente que lleva
asociado un coste, como, por ejemplo: el hardware, el software, el personal, la ubi-
cación, etc.
Facturar. Repercutir de manera real o informativa los costes en los que incurre TI
a consecuencia de la creación de los servicios y de su uso por las áreas cliente.
Mejoras. Las mejoras identificadas en el proceso, bien debido a la necesidad de
optimización de costes, o bien por la detección de deficiencias en otros procesos,
se incorporan al plan general de mejora del servicio.
Modelo de costes en TI. Define la estructura de las partidas presupuestarias y de
la contabilidad analítica de TI. Se debe intentar utilizar una clasificación uniforme
de partidas para el presupuesto y para la contabilidad, y debe estar alineada con la
estructura de la CMDB. El modelo debe balancear entre el suficiente detalle para el
control de los presupuestos y la simplicidad en la contabilidad analítica, de tal forma
que se tenga suficiente información para la toma de decisiones. La obtención de
dicha información debe ser sencilla. Si en el modelo de costes se decidiese conocer
al mínimo detalle el coste de cada tarea, sería necesario, por ejemplo, implantar un
sistema de imputación de tiempos, con una precisión de minutos o de horas, para
todo el personal de TI.
Modelo de facturación de TI. Forma en la que se cobrarán los servicios a las áreas
cliente o, por lo menos, en la que se les informará de los costes incurridos por TI
para proveerlos. El modelo de facturación, visible externamente para el cliente,
debe ser sencillo y, para el control interno de TI, debe alinearse con la estructura
del modelo de costes. La facturación va a permitir que se controle mejor la
demanda de los clientes y la utilización por los usuarios. El cliente valorará aquello
por lo que tiene que pagar, pero por el contrario exigirá precios y calidad equipara-
bles al mercado, y un retorno de valor por su dinero.
Modelo o sistema de gestión de los servicios de TI (SGSTI). Las políticas, y
todos los modelos de costes y facturación se incorporan en el modelo general de
gestión de TI.
Objetivos financieros para TI. En el ciclo de preparación de los presupuestos, la

dirección financiera del negocio establece el marco económico en el que se debe
mover TI que, en estos últimos años, está siendo restrictivo. Estos objetivos econó-
micos que se deben cumplir deben ser acordes con la estrategia general de TI y con
las demandas de las áreas cliente. Por ejemplo, en un entorno expansivo del nego-
cio o de fuerte innovación tecnológica sería difícil garantizar la respuesta de TI si
se estableciera un marco de presupuestos en constante reducción. Normalmente el
“truco” está en que se fuerza una reducción del presupuesto en las partidas de los
costes operativos, permitiendo aumentar así las partidas para la inversión.
Planificación de TI. Los objetivos, el portfolio de servicios, la cartera de proyectos
y las actividades a realizar por TI están estrechamente vinculados con los objetivos
financieros y los presupuestos asignados, pues la mayoría de las actividades de TI
necesitan de un presupuesto para mantenerse. Por tanto, serán necesarias varias rondas
de revisión y negociación con todas las partes para encajar la planificación con el
marco presupuestario.
Política de gestión financiera de TI. Define las directrices que se deben cumplir
por este proceso, necesarias para la definición del modelo de costes y el de factura-
ción (si procede).
Precios. Es recomendable que el catálogo de servicios refleje los precios de los
servicios o, por lo menos, de los costes en los que incurre TI al proveerlos.
Presupuestar. Establecimiento y aprobación de los presupuestos de TI.
Requerimientos financieros del negocio para TI. El departamento financiero, en
representación de la empresa, establece los requerimientos económicos que debe cum-
plir TI (control, reducción de costes, forma de repercusión de los costes, etc.); aprueba
los presupuestos de TI y realiza el seguimiento de los cierres mensuales; y, además, las
áreas cliente reciben una realimentación de los costes de los servicios que demandan y
utilizan. Por otra parte, son las áreas de negocio las que presentan a TI sus necesidades,
quien deberá analizar la forma de cubrirlas en el ámbito del presupuesto establecido.

Las prioridades principales del proceso son el control de los costes de TI y el cono-
cimiento de lo que cuestan los servicios y las principales funciones de TI. En la
figura 6.4.5 se muestran las entradas, actividades y salidas del proceso destinadas a
conseguir estos objetivos.
Las entradas principales que desencadenan el inicio del proceso son la necesidad de
planificar el siguiente ejercicio presupuestario de la empresa y de TI (normalmente
anual), que suele conllevar la definición de unos nuevos objetivos financieros para
TI realizados en función de la planificación de las actividades que se deben realizar;
y de una necesidad de compra que TI inicia y solicita su aprobación presupuestaria.
Hay otras entradas de soporte que se utilizan en el proceso. Destacan los objetivos
financieros establecidos por la organización para TI; la planificación de proyectos y
actividades previstas para TI, donde se reflejan todas las actividades y compromisos
planificados; el modelo de costes, formado por una estructura que permite regis-
trar y asignar todos los costes; el modelo de facturación o imputación de costes a
Desencadenantes 3 Definición de la política de Salidas principales:

del proceso: gestión financiera. Ü Política de gestión
Ü Necesidad de planificar 3 Presupuestar: financiera de TI.
el siguiente ejercicio • Seguimiento del Ü Presupuesto de TI.
presupuestario. presupuesto. Ü Informes de
Ü Necesidad de compra. • Autorizar económicamente seguimiento
las compras. presupuestario.
Entradas de soporte:
3 Contabilizar: Ü Informe de los costes
Ü Objetivos financieros
de TI por servicio y
para TI. • Definir el modelo de costes.
por cliente (*).
Ü Planificación de TI. • Registrar compras y costes.
Ü Facturas por los
Ü Modelos de costes y de 3 Facturar (*): servicios prestados (*).
facturación anteriores.
• Definir precios.
Ü Petición de informes Salidas secundarias:
• Emisión de facturas.
económicos y consultas. Ü Planificación de TI
Ü CMDB y catálogo de 3 Identificación de mejoras ajustada.
servicios. en TI. Ü Informes e información
3 Supervisión del económica. Ratios de
funcionamiento del proceso. costes.
Mejora del proceso. Ü Autorizaciones a
compras.
Ü Modelo de costes en TI.
Ü Modelo de facturación.
Ü CMDB actualizada.
Ü Precios del catálogo
actualizados.
(*)
No requerido por ISO/IEC 20000.

clientes; diversas peticiones de informes y consultas económicas sobre TI; y la

CMDB, para identificar los elementos intervinientes en un servicio y el catálogo de
servicios, con el fin de identificar los costes de los servicios ofrecidos.
Las principales actividades que realiza este proceso son la definición de la política
de gestión financiera, a partir de los requerimientos y objetivos del negocio para
TI; la elaboración del presupuesto (presupuestar), que tiene como objetivo dotar
de recursos económicos a TI en función de las predicciones de gasto (dentro de esta
actividad se realiza el seguimiento del presupuesto para controlar su evolución, y la
autorización económica de las compras para garantizar que se gastan sólo las parti-
das comprometidas); la contabilidad de los servicios de TI, que tiene como obje-
tivo llevar un registro completo de la forma en que se gasta el presupuesto; la fac-
turación de los servicios de TI, para gestionar la imputación de los costes a los
clientes por los servicios ofrecidos; y la supervisión del funcionamiento del proceso
y las acciones de mejora del mismo, que permiten ir eliminando las ineficiencias y
la tendencia natural del control económico hacia la burocracia.
Las salidas principales del proceso son el documento con la política de gestión
financiera de TI definida; el presupuesto económico de TI para el ejercicio; los
informes de seguimiento presupuestario, que proporcionan información de la
situación actual y de los cierres presupuestarios intermedios; y la información del
coste de los servicios prestados a los clientes, ya sea en forma de facturación real o
mediante un informe específico.
Entre las salidas secundarias destacan la planificación general de TI ajustada y
modificada acorde con los presupuestos; informes e información económica
diversa, así como, ratios económicos (coste por usuario, coste por capacidad de
proceso, etc.); las autorizaciones económicas a las compras de TI; los documentos
con el modelo de costes de TI y el modelo de facturación; la CMDB actualizada en
cuanto a los costes de los elementos de configuración y servicios; y el catálogo
de servicios actualizado con los precios revisados.
Interrelación con otros procesos y áreas de TI

La gestión financiera de TI está estrechamente ligada a otras áreas y procesos: el
área financiera de la empresa, la gestión de las relaciones con el negocio, la gestión
de nivel de servicio, la gestión de la capacidad, la gestión de la disponibilidad-con-
tinuidad y la gestión de suministradores.
Área financiera de la empresa. El proceso de gestión financiera de TI es receptor
de los requerimientos del negocio para TI en sus aspectos económicos y los des-
pliega. Además, negocia los presupuestos e informa periódicamente de su ejecución.
El objetivo es conseguir que la gestión financiera de TI esté integrada completa-

mente en la gestión financiera general de la empresa. Para ello es necesario que los
requerimientos específicos de TI se reflejen en ésta última. El presupuesto de TI se
realiza igual que en el resto de departamentos de la empresa, la contabilidad utiliza
los sistemas contables de la empresa y la facturación se realiza a través del área
financiera o de cobros. En la figura 6.4.6 se ilustra esta integración.
DEPARTAMENTO FINANCIERO DE LA EMPRESA
PRESUPUESTO CONTABILIDAD FACTURACIÓN
• Necesidades • Necesidades de • Detalles de

presupuestarias de TI. clasificación contable consumo TI
• Cumplimiento para TI. de los clientes
presupuesto. • Desglose de los
costes TI incurridos
GESTIÓN FINANCIERA DE TI
SISTEMAS DE
INFORMACIÓN
MARKETING VENTAS FABRICACIÓN ADMINISTRACIÓN SERVICIOS Etc.
GENERALES
Figura 6.4.6. Integración de la gestión financiera de TI con

la gestión financiera de la empresa
Relaciones con el negocio. Cuando se definen los presupuestos es necesario man-

tener reuniones con los clientes para acordar los servicios que se van a prestar en el
ejercicio, su evolución y sus precios. Esta negociación se lleva a cabo a través del
proceso de las relaciones con el negocio.
Gestión de nivel de servicio. La gestión de nivel de servicio acuerda con la gestión
financiera la presupuestación de los recursos necesarios para cumplir los niveles de
servicio pactados y la financiación de los planes de mejora del servicio (SIP). Por
ejemplo, si se negocia con un cliente la atención en fines de semana, será necesario
tener presupuestado y aprobado este coste extra antes de cerrar el SLA. Con la ges-
tión de nivel de servicio también se analizan las mejoras de eficiencia en costes de
los servicios. Además, en el catálogo de servicios se incorpora el precio de cada ser-
vicio y sus opciones.
Gestión de suministradores. La gestión de suministradores está muy vinculada a
este proceso. Las relaciones entre ambos se establecen en todos los ámbitos de la
gestión de suministradores: en la definición de la estrategia de sourcing, que debe
ser acorde con los objetivos financieros; en el ciclo de selección y contratación, que
lleva a cabo las compras; y en el ciclo de gestión de la prestación del suministrador,
para velar por los pagos y las variaciones económicas dependientes de la demanda.
Gestión del cambio. Los cambios importantes deben valorarse en cuanto al coste
y aprobarse bajo el ámbito de la gestión del cambio. Este requisito obliga a la ges-
tión financiera a trabajar de una forma conjunta con el resto de la organización en
la aprobación de los cambios y sus costes bajo el proceso de gestión del cambio.
Gestión de la capacidad. La gestión de la capacidad participa en la elaboración de
los presupuestos con las previsiones de recursos identificadas en el plan de capaci-
dad. Con las previsiones, se pueden concentrar las compras y evitar las compras de
urgencia para obtener ahorros adicionales. Además, proporciona información sobre
la utilización de las infraestructuras y de los recursos.
Gestión de la disponibilidad y continuidad. La continuidad puede requerir gran-
des inversiones en replicaciones, en servicios externos y en centros redundados. La
elaboración de presupuestos y contabilidad debe conseguir que las soluciones de
continuidad tengan el equilibrio entre el coste y el beneficio aportado al negocio.
Pues, podría ocurrir que la pérdida posible del negocio sea menor que el coste de
los mecanismos redundados.
Gestión de la configuración. La información sobre los costes de los activos los
proporciona el proceso de gestión financiera, y gestión de la configuración los
almacena como un atributo de información más. Posteriormente se utilizarán para
el cálculo de los costes por servicio.
Este proceso también se relaciona con el resto de procesos y áreas para definir las
partidas presupuestarias del ejercicio, identificar mejoras de eficiencia económica y
el seguimiento de los objetivos económicos.
Alcance del proceso

El apartado 6.2 de las Normas ISO/IEC 20000 cubre únicamente la definición de
las políticas, la realización de los presupuestos y la contabilidad de los servicios
de TI. Pero en la práctica, se está implantando también la facturación de los servi-

cios a los clientes, como uno de instrumentos para lograr unos servicios eficientes
alineados en términos de coste con las necesidades del negocio. En estas normas se
aclara el alcance que cubren:
UNE-ISO/IEC 20000-1
Nota: Esta sección cubre la elaboración de presupuestos y de la contabilidad del los servicios de TI. En
la práctica, muchos proveedores del servicio estarán involucrados en facturar por tales servicios.
Sin embargo, dado que la facturación es una actividad opcional, no está cubierta por la norma.
Se recomienda a los proveedores que si hacen uso de la facturación, el mecanismo para hacerlo
esté plenamente definido y entendido por las partes. Todas las prácticas contables en uso se debe-
rían alinear con las prácticas contables más amplias de la organización del proveedor del servicio.
En la nota anterior se deja claro el alcance de los requisitos del proceso en la parte 1,
en los que no se incluye la facturación, aunque en este libro sí se trata.
Por otra parte, se recalca la importancia de que la elaboración de presupuestos y la
contabilidad de TI estén perfectamente alineadas con las prácticas contables gene-
rales de la organización. Hay que intentar que la contabilidad de la empresa con-
temple las necesidades de la contabilidad analítica de TI, con el fin de poder extraer
de ésta los costes por servicio, los costes por cliente, los costes por actuación, etc.
Así, se evita realizar la contabilización dos veces, una en los sistemas contable gene-
rales de la empresa y otra en los sistemas contables específicos de TI.
UNE-ISO/IEC 20000-2
Generalidades
La responsabilidad sobre muchas de las
Esta sección cubre la realización de los decisiones financieras va a estar fuera
presupuestos y de la contabilidad para del ámbito de la gestión del servicio y
los servicios de TI. En la práctica, también podrían dictarse externamente
muchos proveedores están implicados los requisitos acerca de qué información
en la facturación del servicio. Sin financiera se debe facilitar, de qué
embargo, dado que la facturación es manera y con qué frecuencia. Las dis-
una actividad opcional, no está cubierta posiciones de esta sección están enfo-
por esta norma. Se recomienda a los cadas en las prácticas que se deberían
proveedores del servicio que cuando seguir para satisfacer los requisitos de la
lleven a cabo la facturación, el meca- norma. Sin embargo, se pueden tener
nismo empleado para ello esté definido en cuenta requisitos más amplios en el
en detalle y sea entendido por todas las caso de que impacten en alguna de las
partes implicadas. políticas y procedimientos definidos.
ISO/IEC 20000-2 hace hincapié en que muchas decisiones financieras que afectan
a este proceso se toman fuera de él. La gestión financiera de TI está supeditada a
las directrices del departamento financiero de la organización. En algún escenario,
como en el caso de las empresas pequeñas, la responsabilidad completa del proceso
puede ser externa a TI.
Planificación e implementación del proceso

La planificación e implementación del proceso de gestión financiera de TI se reali-
zará por el mismo equipo especialista en procesos que se encarga de definir las for-
mas de trabajar en toda la organización de TI. Este equipo colaborará estrecha-
mente con el futuro responsable de la gestión financiera de TI. La implementación
de este proceso no debe realizarse aisladamente, sino como parte de la implementa-
ción de todo el sistema de gestión de TI (véase el capítulo 3), que se realizará
siguiendo el rigor del ciclo PDCA establecido en el “proceso de implementación
de la gestión del servicio” (véase el capítulo 4).
Los principales aspectos a tener en cuenta en la implementación del proceso son:
• Un firme compromiso de la dirección con el proceso de gestión financiera
de TI, pues toda la organización de TI deberá asumir y adaptarse a los pre-
supuestos acordados. Además, cada compra deberá ser aprobada en sus
aspectos de encaje presupuestario.
• Una clara asignación de responsabilidades, para que la organización de TI
acepte sin dudas la figura del gestor económico de TI. Este proceso tiene un
control estrecho de los gastos de toda la organización de TI, que general-
mente se percibe como burocrático y con poca aportación de valor. Es nece-
sario vencer la resistencia de los participantes en el resto de procesos y del
resto de los departamentos.
• Un plan adecuado de comunicación, que informe a todos los responsables y
usuarios de la organización de TI de las ventajas de una correcta gestión de
la elaboración del presupuesto y contabilización de los servicios de TI.
• La sencillez en la implementación, descendiendo sólo al nivel de detalle nece-
sario.
• Transparencia en la información presupuestaria y su ejecución, incorporán-
dolos al modelo de documentación estructurado para ofrecer información y
ayuda online a toda la organización de TI.
• La necesidad de definir una política de gestión económica de los servicios de
TI que marque las reglas de funcionamiento.
• Las herramientas de soporte a la gestión del proceso deben ser los mismos
sistemas de gestión de la empresa. Deben permitir gestionar los presupues-
tos, la contabilización de los gastos por servicio y por cliente, el registro del
consumo de recursos y su facturación.
• Contemplar los propios costes originados por el proceso, que esencialmente
están relacionados con el personal y la adaptación de los sistemas financieros
de la empresa.
Definición de la política de gestión financiera

A partir de los requerimientos y objetivos del negocio para TI, se desarrollan las
principales directrices económico-financieras para las cuales el proceso debe garan-
tizar su cumplimiento por el resto de la organización de TI.
La misión de toda política es definir los objetivos que se deben alcanzar y preparar
un marco de directrices para conseguirlos. En las Normas ISO/IEC 20000 se
requiere que exista una política para la gestión financiera de los servicios de TI, es
decir, que se presupuesten y contabilicen todos los componentes, que se repercutan
los costes directos e indirectos de los servicios y que haya un control económico y
sus procedimientos de autorización.
UNE-ISO/IEC 20000-1
Debe haber políticas y procedimientos claros para:

a) presupuestar y contabilizar todos los componentes, incluyendo los activos de
tecnologías de la información, recursos compartidos, gastos generales, servi-
cios suministrados externamente, personas, seguros y licencias;
b) la repercusión de costes indirectos y la asignación de costes directos a servi-
cios;
c) el control económico efectivo y la autorización.
ISO/IEC 20000-2 desarrolla el contenido recomendado para la política financiera

de TI, en la que se detallan los tipos de costes que se deben contabilizar, la forma
de repercusión de los gastos generales comunes, el grado de detalle que se debe
alcanzar, cómo se gestionarán las desviaciones presupuestarias, la relación con la
gestión de nivel de servicio, etc.
UNE-ISO/IEC 20000-2
Política ejemplo el nivel de variación nece-

sario para que se escale a la alta
Debería existir una política para la ges-
dirección;
tión financiera de los servicios. La polí-
tica debería definir los objetivos a ser e) los enlaces o vinculación con la
cumplidos por la realización de los pre- gestión de nivel de servicio.
supuestos y la contabilidad.
El nivel de inversión en los procesos de
La política debería definir también el elaboración del presupuesto y contabili-
nivel de detalle al que se lleva a cabo la dad debería estar basado en las necesi-
elaboración de los presupuestos y la dades de detalles financieros que ten-
contabilidad, teniendo en cuenta: gan los clientes, el proveedor del
a) los tipos de costes a ser contabili- servicio y los proveedores, según esté
zados; definido en la política.
b) el reparto de los gastos generales, Nota: Los proveedores del servicio que operen en
por ejemplo reparto en partes igua- un entorno comercial podrían necesitar
les, reparto porcentual o reparto invertir mucho más esfuerzo y tiempo en la
gestión financiera. Contrariamente, para
basado en el tamaño de los ele- aquellos proveedores del servicio que sólo
mentos variables empleados; necesiten la simple identificación de los
costes, esta gestión puede ser mucho más
c) la granularidad del negocio del simple.
cliente, por ejemplo unidades de
negocio tomadas como una sola, La realización de los presupuestos y la
dividas en departamentos o según contabilidad se deberían realizar por
las diferentes ubicaciones; todos los proveedores del servicio, cua-
d) las reglas para manejar las varia- lesquiera que fueran sus otras políticas
ciones frente al presupuesto, por en cuanto a gestión financiera
En la política se define el modelo de costes, con foco en los criterios de asignación

de costes por servicio. Este modelo debe ser:
• Sencillo. Con mecanismos de cálculo de costes simples y fácilmente enten-
dibles por los clientes. También se debe buscar la sencillez en la gestión, para
evitar la burocracia que comúnmente se asocia a este tipo de actividades, con
el fin de proporcionar una mayor eficiencia global.
• Justo. El sistema de asignación de costes debe ser ecuánime y realista, ya que
aquellos servicios que no sean eficientes en términos de coste se deberán
revisar y, en muchos casos, habrá que tomar medidas drásticas. Realmente
cada unidad de negocio debería pagar el mismo precio por el mismo servicio.
• Realista. Uno de los puntos clave es buscar la eficiencia económica de los

servicios. Por tanto, los mecanismos de gestión económica de los servicios
de TI se deben diseñar para conseguir esta eficiencia. Pero, el ahorro en TI
debe contemplar que el resultado final no sea un mayor gasto o ineficiencia
en el negocio.
La política de gestión financiera debe ajustarse al tipo de organización. Por ejem-

plo, si el negocio de la empresa es la venta de los servicios de TI al mercado, reque-
rirá un sistema de gestión económica que permita la imputación de costes y la asig-
nación a clientes de forma justa, sencilla y realista. Por el contrario, en el caso de
unidades de TI internas, los objetivos del proceso podrían limitarse únicamente al
conocimiento de los costes totales incurridos en la prestación los servicios de TI, de
modo que los clientes sean conscientes de lo que cuestan sus demandas agregadas.
Al principio de la implantación de una política de gestión financiera de los servi-
cios de TI, al cliente le puede parecer que los costes de los servicios son altos y que
la relación con TI se vuelve más burocrática, pues se incluye la gestión económica
en la toma de decisiones. Para limitar este riesgo, la política debería considerar:
• Los aspectos de comunicación, transparencia y difusión del proceso y sus
objetivos.
• Que los modelos de cálculo de costes se desarrollen en coordinación con los
clientes.
• La propia eficiencia del proceso.
Estructura común de elementos de coste

De cara a mantener una gestión financiera sencilla y homogénea en TI se reco-
mienda definir una estructura común de elementos de coste, a modo de tesauro
contable, que permita clasificar los presupuestos y los costes con los mismos crite-
rios. Así, se utilizarán desgloses similares en la elaboración del presupuesto, en la
contabilización y en el cálculo de costes para la facturación. Esta misma clasifica-
ción se debería mantener entre las grandes áreas de TI: en el puesto de trabajo, en
el centro de datos o explotación de sistemas, y en el desarrollo de aplicaciones.
Se propone utilizar la misma estructura de elementos de coste definida en ITIL v2:
costes de hardware, costes de software, costes de personal, costes de ubicación
física, costes de servicios externos y costes de transferencia (imputaciones de otras
áreas de la empresa). En la figura 6.4.7 se muestra el detalle de esta estructura pro-
puesta para la clasificación de los datos económicos.
Figura 6.4.7. Propuesta de una estructura común de los elementos de coste en TI
Elaboración del presupuesto (presupuestar)

La elaboración del presupuesto consiste principalmente en realizar una estimación
detallada de los gastos e inversiones necesarios para la provisión, mantenimiento y
evolución de los servicios de TI, teniendo en cuenta las necesidades de los clientes
y asegurar que se proporcionen a TI los fondos necesarios. Bajo presupuestar se con-
templa también el seguimiento diario de la ejecución del presupuesto, el control eco-
nómico de las compras y la autorización de los posibles desvíos presupuestarios.
El presupuesto se formaliza generalmente en períodos anuales. Se establece
mediante tres ciclos de negociaciones: entre TI y el área financiera de la empresa,
para acordar los montos totales y las principales partidas; entre la gestión financiera
de TI y las áreas internas de TI, para conocer las necesidades y ajustar las partidas;
y entre TI y las áreas cliente, con el fin de adecuar el presupuesto a sus necesidades.
Entre los tres ciclos de negociación hay una realimentación hasta alcanzar un equi-
librio.
El presupuesto dota económicamente a TI y, por tanto, condiciona toda la acti-

vidad en el ejercicio. Debe ir estrechamente vinculado al desarrollo de la estrategia
de TI.
Las Normas ISO/IEC 20000 requieren que los presupuestos tengan el suficiente
detalle para posibilitar el control económico y la toma de decisiones.
UNE-ISO/IEC 20000-1
Los costes se deben presupuestar con suficiente detalle para permitir el control eco-
nómico efectivo y la toma de decisiones.
El proveedor del servicio debe monitorizar e informar de los costes contra el presu-
puesto, revisar las previsiones económicas y gestionar los costes en consonancia.
Los costes de los cambios en el servicio se deben valorar y aprobar a través del pro-
ceso de gestión del cambio.
ISO/IEC 20000-1 requiere que los cambios se valoren en cuanto a sus costes y que
se aprueben a través del proceso de gestión del cambio. De esta forma, se tiene
un mejor conocimiento y control de los costes. Las peticiones de cambio (RFC),
presentadas con el fin de aprobar su ejecución, deben incorporar el coste asociado
(así se establece en el formato de RFC del apartado 9.2). El proceso de gestión
financiera controlará a través de su presencia en el comité de cambios (CAB,
Change Advisory Board), que se actué dentro de los presupuestos asignados.
Una vez aprobado el cambio, cuando se necesite la ejecución de alguna compra
(equipamiento, licencias, servicios, etc.), volverá a intervenir la gestión financiera
para autorizarla económicamente.
UNE-ISO/IEC 20000-2
Elaboración del presupuesto ficar la gestión que se va a hacer del

déficit.
La elaboración del presupuesto debe-
ría tener en cuenta los cambios planifi- La elaboración de los presupuestos
cados de los servicios durante el puede tener en cuenta factores tales
periodo presupuestario y, en el caso de como variaciones estacionales y cam-
que las necesidades presupuestarias bios planificados a corto plazo en los
excedan los fondos disponibles, plani- costes y facturación de los servicios.
El seguimiento de los costes frente al La elaboración de los presupuestos y

presupuesto debería facilitar lo antes el seguimiento de los costes deberían
posible la información de las variacio- dar soporte a la planificación de la
nes frente al presupuesto. operación de cambios en los servicios
para que los niveles de dichos servi-
Se debería establecer un proceso para
cios puedan mantenerse a lo largo del
gestionar las implicaciones de las varia-
año.
ciones frente al presupuesto.
Aunque no existe forma estándar de realizar el presupuesto de TI, se suelen utilizar

dos estrategias:
• Presupuesto incremental: se toma como punto de partida el presupuesto
del año anterior, y sobre él se corrigen las partidas, teniendo en cuenta la
variación de los precios, de la planta, de la actividad, de los servicios, etc.
• Presupuesto “con base cero”: en este ejercicio se parte de una hoja en
blanco para replantear y cuestionar todas las necesidades y partidas presu-
puestarias. Esta forma, más laboriosa, tiene como ventaja que se detectan
mejor las partidas presupuestarias repetitivas que aportan poco valor. Cada
partida que se incluye hay que justificarla. Se corre el riego de olvidar com-
promisos o partidas necesarias, como por ejemplo, los mantenimientos.
El presupuesto es una “tabla” en la que se relacionan las partidas presupuestarias

que se deben considerar, junto con el monto económico acordado para cada una de
ellas en el ejercicio. El nivel de detalle y su clasificación depende de las prácticas
financieras de cada organización. Se debe mantener la misma estructura clasificato-
ria en el presupuesto que en la contabilidad que registra su ejecución. En la figura
6.4.8 se muestra una plantilla para la elaboración de un presupuesto.
Además, en el presupuesto se suele discriminar entre inversión (coste de capital o
CAPEX) y coste operativo (OPEX). La inversión aumenta el valor de la empresa,
se presupuesta según la forma de pago prevista en la compra y se imputa contable-
mente en el transcurso del período de amortización.
En el presupuesto conviene también detallar a nivel mensual las partidas con el fin
de poder realizar de forma más precisa el seguimiento presupuestario.
En la elaboración de un presupuesto además hay que considerar otros aspectos
como por ejemplo:
• Los límites para la inversión.
• Los límites para el coste operativo.
Figura 6.4.8. Plantilla simplificada para la elaboración de un presupuesto de TI
• La variación permitida entre los gastos reales y los previstos.

• Se debe confeccionar una guía de cómo utilizar el presupuesto y cómo reali-
zar el seguimiento.
• Se debe establecer el tratamiento de las excepciones.
En teoría, antes de la realización del presupuesto, se deberían tener cerradas las pro-
puestas de los planes anuales de los otros procesos y áreas, que tienen una influen-
cia directa en el presupuesto, como por ejemplo, el plan estratégico de TI, la car-
tera de proyectos anual, el plan de capacidad, el plan de continuidad, el plan de
disponibilidad y las estimaciones de costes de otras áreas y procesos (service desk,
problemas, cambios, infraestructuras, etc.).
Seguimiento del presupuesto. Una vez aprobado formalmente el presupuesto,

puede comenzar su ejecución con el fin de ir nutriendo a TI de los recursos que
necesita. Para garantizar que el presupuesto se gasta en las partidas comprometidas

y que se ejecuta según lo previsto, es necesario realizar un seguimiento presupues-
tario periódico que controle la evolución del gasto.
El seguimiento presupuestario conlleva la realización de cierres intermedios, (habi-
tualmente mensuales) en los que se totalizan todos los elementos de coste y se com-
prueba que evolucionan según lo previsto. Estos cierres se almacenan a modo de
“línea base presupuestaria” y se comunican a los interesados a través de los infor-
mes de seguimiento presupuestario. De esta forma, cuando de detecten desviacio-
nes en algunas partidas se podrá actuar estableciendo acciones correctoras antes de
que sea demasiado tarde.
Esta actividad de seguimiento se realiza utilizando el sistema o herramienta conta-
ble (general de la empresa), para generar de forma automatizada los informes de
evolución de los costes y su comparación con los presupuestos.
La actividad de seguimiento presupuestario se suele hacer (según ITIL v2):
• Diaria o semanalmente:
– Recoger los datos de los costes incurridos y comprobar que son exactos y
completos.
– Participar en la valoración de los cambios y si es necesario asistir a las reu-
niones del comité de cambios (CAB).
• Mensualmente:
– Comprobar que los costes consolidados del mes en curso se corresponden
con las previsiones, y analizar y explicar cualquier desviación.
– Realizar análisis de costes.
– Obtener los precios reales por servicio-cliente, y compararlos con los pre-
supuestos.
– Difundir un balance de situación mensual.
– Notificar las desviaciones producidas a cada área.
– Revisar la recuperación de los costes en comparación con los objetivos
establecidos.
• Trimestral o semestralmente:
– Evaluar la exactitud de las fórmulas para el cálculo de costes, comparando
los costes y los ingresos reales con los previstos.
– Comprobar las listas de precios de los servicios.
– Determinar la exactitud de las previsiones para mejorarlas en el futuro.

– Preparar el ciclo anual del presupuesto realizando previsiones trimestrales
o semestrales.
• Anualmente:
– Planificar los cambios necesarios en el personal y los recursos para el pró-
ximo año.
– Revisar los sistemas de contabilidad y facturación de TI, para:
· Generar las cuentas finales del año financiero en curso.
· Asegurar de que se alcanzan los objetivos de negocio de la organización
de TI.
– Generar los análisis anuales del coste.
– Confeccionar y difundir un balance final.
– Revisar los elementos de coste estándar (es importante tener en cuenta
que las correcciones deben ser las imprescindibles, ya que cualquier cam-
bio dificultará las comparaciones entre distintos años).
– Recalcular el valor por unidad del coste para comprobar que se correspon-
den con los resultados previstos.
– Revisar la política de gestión económica y los procedimientos de la conta-
bilidad de TI.
– Ayudar al cliente y a otros gestores de TI a definir los presupuestos para el
nuevo año financiero.
– Revisar las necesidades de continuidad de los servicios que soportan la
gestión económica de TI, y comprobar que todos sus requerimientos y
necesidades están cubiertos.
Autorizar compras. La conversión del presupuesto en recursos disponibles para

TI se realiza principalmente a través de las compras o contrataciones a suministra-
dores (véase también el apartado 7.3). Dentro del ámbito de presupuestar, también
se contempla la autorización económica de las compras. Toda compra, antes de eje-
cutarse, debe ser autorizada por este proceso con el fin de garantizar que tiene una
partida asignada y que se encuentra dentro del plan previsto. De esta forma, se con-
trolan las desviaciones antes de que se produzcan. Para agilizar las compras, se sue-
len preautorizar grandes partidas sobre las que se ejecutan compras al detalle (por
ejemplo, compra de PC, de consumibles, etc.).
Contabilidad de los servicios de TI

El objetivo principal de la contabilidad es conocer el coste real de la provisión y del
mantenimiento de los servicios de TI. La contabilidad lleva un registro completo
de la forma en la que se gasta el presupuesto.
La contabilidad de los servicios viene a paliar el desconocimiento histórico de los
costes a nivel servicio. La razón principal proviene de la utilización de plataformas
y recursos comunes, lo que genera dificultades a la hora de repartir los costes hasta
el último nivel. La evolución del mercado y el mayor peso de los costes de TI en la
estructura empresarial, hacen absolutamente imprescindible el conocimiento del
coste de cada servicio.
Como TI es un área más de la empresa, se debe poner énfasis en que la contabili-
dad la realice el departamento contable de la empresa y no el personal de TI. Se
debe evitar tener una actividad de contabilización paralela. Para conseguir este
objetivo, hay que gestionar la incorporación del modelo de costes definido para TI
en el sistema contable de la empresa. En ocasiones, TI prefiere mantener los deta-
lles de sus presupuestos y costes a resguardo, con el fin de tener más margen de
maniobra y no dar explicaciones a otras áreas.
En este ámbito, las Normas ISO/IEC 20000 aportan unas recomendaciones muy
livianas:
UNE-ISO/IEC 20000-2
Contabilidad
Los modelos de costes deberían ser
Los procesos de contabilidad se debe- capaces de mostrar los costes de la pro-
rían usar para realizar el seguimiento de visión del servicio.
los costes hasta el nivel de detalle acor-
Los estados de cuentas deberían mostrar
dado durante un periodo de tiempo
las situaciones de excesos y defectos
también acordado.
de gasto así como las recuperaciones de
Las decisiones sobre la provisión del dichas situaciones y deberían permitir al
servicio deberían estar basadas en com- lector entender los costes de niveles bajos
paraciones sobre la eficacia en costes. de servicio o de pérdidas de servicio.
Se debe poner un foco especial en conocer el gasto por cliente, por servicio y por
actividad, lo cual implica tener que realizar un desglose o asignación por cliente y
por servicio en todos los gastos. En lo relativo a la actividad, se necesitará un sis-
tema de imputación de tiempos por parte del personal.
La información proporcionada por contabilidad y el seguimiento presupuestario

de TI, es esencial para mantenerse en el marco del presupuesto asignado, la toma
las decisiones sobre inversiones y renovaciones de contratos, e identificar ineficien-
cias y actividades que no aporten valor.
El establecimiento de la contabilidad de TI puede resultar una tarea compleja si se
implementa con un nivel de detalle excesivo y puede llegar a costar más que los
beneficios que aporta.
Un buen sistema contable debe:
• Permitir realizar el seguimiento de los costes reales y compararlos con el pre-
supuesto.
• Proporcionar información de los costes incurridos para la prestación del ser-
vicio con el rendimiento requerido.
• Facilitar la evaluación y establecimiento de las prioridades de la utilización
de recursos.
• Facilitar el seguimiento de los costes y la toma las decisiones diarias con una
comprensión plena de las implicaciones en cuanto a costes y, con el mínimo
riesgo.
• Dar soporte a la actividad de facturación de los servicios de TI, si la organi-
zación lo considera necesario.
Modelo de costes en TI. Un modelo de costes por servicio es una estructura con-
table en la que se pueden registrar y asignar todos los costes conocidos a servicios,
de manera que se puedan conocer los costes de toda la estructura productiva nece-
saria para un servicio. De igual manera, existe el modelo de costes por cliente (mar-
keting, ventas, etc.), que permite conocer todos los costes incurridos por TI para
prestar los servicios a cada uno de ellos.
El modelo de costes de TI se debe definir e implementar de forma conjunta entre
TI y el área financiera de la empresa. De esta manera, además de cumplir con la
legalidad vigente, se evita tener que realizar una contabilidad duplicada.
A la hora de plantear el desarrollo e implantación de un modelo de costes, y antes
de lanzarse a definir los elementos de coste típicos de TI, se debería obtener la
siguiente información.
• La información procedente de las cuentas de gasto de la empresa a la que
pertenece la organización de TI (gastos de personal, contratos de servicios
de TI, mantenimiento de licencias, amortización del hardware y del soft-
ware, etc.).
• El catálogo de servicios de TI de la organización.

• El detalle de los servicios de TI y la infraestructura que los soporta. En esta
tarea resulta de gran utilidad disponer de una CMDB actualizada.
El modelo de costes es un aspecto clave y piedra angular para una adecuada ges-
tión económica de los servicios de TI. En la figura 6.4.9 se muestra el ejemplo de
un modelo de costes de TI enfocado a los servicios.
Hardware Software Personal Ubicación Servicios externos Transferencia
Elementos de coste
Costes directos Costes indirectos Costes indirectos

del servicio imputables al servicio no imputables
Hardware Hardware Hardware
Software Software Software
Personal Ubicación Personal
Servicios externos Ubicación
Servicios externos
Transferencia
Costes directos Costes indirectos
del servicio del servicio
Reglas de
Costes directos y % de
reparto de los
costes absorbidos incremento
costes indirectos
del servicio común
no imputables
Coste total del servicio
Figura 6.4.9. Ejemplo de un modelo de coste por servicio

El modelo de costes por servicio es una forma de asignar internamente los costes
con el fin de conocer el coste total de prestación de cada servicio. Para ello, prime-
ramente se obtiene la información contable por elemento de coste según la estruc-
tura común definida: costes de hardware, costes de software, costes de personal,
costes de ubicación física, costes de servicios externos y costes de transferencia.
Una vez recopilados todos los costes, se clasifican los costes en dos tipologías,
directos o indirectos:
• Costes directos del servicio. Son aquéllos que pueden atribuirse de manera
clara a un único servicio. Por ejemplo: un servicio que se ejecuta en una
máquina específica.
• Costes indirectos. Son aquéllos en los que se incurre de forma común a
todos los servicios o en un número acotado de ellos. Por ejemplo, la red o el
departamento de soporte técnico, que tendrán que ser distribuidos entre
todos de manera equitativa. Al distribuir los costes indirectos se dan dos
casos:
– Costes indirectos imputables a un servicio. Son aquellos costes
de recursos comunes que razonablemente se pueden imputar a un ser-
vicio mediante un tipo de prorrateo por el uso que hace el servicio del
recurso. Por ejemplo, el consumo de CPU de un servicio en una máquina
virtual.
– Costes indirectos no imputables a un servicio o no absorbibles. Es el
coste de cualquier recurso que presta servicios de una forma común a
todos y que no tiene una relación posible con un servicio o cuya imputa-
ción es muy compleja. Se repercute entre todos los servicios del modo más
justo posible. Estos elementos comunes pueden ser de hardware, de soft-
ware, de personal, de ubicación, de servicios externos o de transferencia.
Por ejemplo, un cortafuegos del centro de datos, los sistemas de aire acon-
dicionado, el personal administrativo, etc. En este caso, los costes se dis-
tribuyen en base a una tasa común que incrementa los costes del servicio
calculados hasta ese momento.
La suma de los costes totales asignados a los servicios debe ser igual a la suma de
los costes iniciales.
Registrar las compras y los costes. La actividad fundamental de la contabiliza-

ción es el registro de los costes incurridos. Los costes en TI se incurren a través de
una compra o a través de una imputación interna de otro departamento, como por
ejemplo, los costes de personal (nóminas, viajes, administración, etc.) o los de
transferencia (imputaciones de otras unidades como servicios generales o seguri-

dad física).
La misión principal en esta actividad es conseguir que el departamento de contabi-
lidad realice las anotaciones contables contemplando las necesidades de TI. Para
ello, TI deberá colaborar en proporcionar información precisa sobre el desglose de
las partidas en cada una de las compras adjudicadas (equipamiento hardware, pro-
ductos software, consultoría, servicios técnicos, formación, etc.).
Facturación de los servicios de TI

La facturación es el conjunto de tareas que permite calcular el precio de los servi-
cios de TI que utilizan los clientes y la emisión de las facturas asociadas. Requiere
que se fijen unos precios justos y entendibles por todas las partes y que se lleve un
registro del consumo o utilización de estos recursos.
Las Normas ISO/IEC 20000 no cubren esta actividad por considerarla un requeri-
miento no generalizable a todas las organizaciones. Otras buenas prácticas del mer-
cado, como por ejemplo ITIL, sí recomiendan establecer una relación tipo comer-
cial entre TI y sus clientes internos. La facturación es especialmente útil para
moderar la demanda de los clientes.
La facturación, condicionada por la información aportada por la contabilidad e ins-
pirada en la experiencia del mercado en la facturación de productos y servicios,
debe ser también sencilla (precio por usuario, precio por servicio, precio por trans-
acción, etc.).
Existen dos situaciones de partida muy distintas. Una, que la empresa venda los
servicios de TI al exterior (al mercado o a las empresas pertenecientes a un mismo
grupo), en cuyo caso la facturación es obligada y se realiza a través del canal de fac-
turación-cobros habitual de la empresa; y otra, que TI sea un departamento
interno. En este caso TI envía los detalles de los consumos y los precios acordados
al departamento financiero de la empresa, para que proceda a la imputación o
transferencia de los costes a las áreas cliente. En ambos escenarios, el contacto con
el cliente se realiza bajo el proceso de relaciones con el negocio.
Muchas organizaciones de TI consideran que la facturación interna no es una tarea
prioritaria. En caso de no realizarse la facturación real, es aconsejable que al menos
se informe al cliente de los costes en los que ha incurrido por los servicios prestados.
Cuanto más precisa es la facturación, mayor esfuerzo se requiere en la contabiliza-
ción de los gastos. Cada organización debe encontrar su punto de equilibrio entre
el detalle deseado y la complejidad asociada.
Existen diferentes tipologías a la hora de calcular los costes, las dos más utilizadas
son:
• En base al coste total de la propiedad o TCO (Total Cost of Ownership), que
calcula todos los costes necesarios durante el ciclo de vida completo del
servicio. En este caso, los clientes soportan la totalidad de los costes de pro-
visión y prestación del servicio.
• En base al coste marginal, calculando el coste en función del incremento en el
total de costes por proveer un servicio adicional. Sólo se repercuten al cliente
los costes incrementales del ejercicio. Es una forma más sencilla e imprecisa de
repercutir los costes, pero igualmente sirve para moderar la demanda.
Los modelos más utilizados para la distribución de los costes en función de los con-
sumos son:
• Coste por usuario de los servicios. En este modelo, se carga una cuota fija
por cada usuario con independencia del uso que se realice. Muy utilizado en
los servicios al puesto de trabajo (PC, archivos en red, navegación por Inter-
net, correo electrónico, etc.). Es un modelo sencillo, pero poco equitativo.
Para que tenga su efecto de moderar la demanda, debe combinarse con otros
costes que sean reflejo del consumo variable. También se utiliza para reper-
cutir los costes de las aplicaciones con complejidad de administración o
cuando el coste de las licencias es alto.
• Coste por capacidad de proceso consumida. Forma histórica de medición
en el ámbito mainframe. Las mediciones son sencillas y las proporciona el
propio sistema. Se factura por tiempo de uso del procesador. El coste por
MIP (Millones de Instrucciones por Segundo) en el mainframe, o por MIP
equivalente para entornos abiertos, es un dato con benchmarking del mercado.
• Coste por servidor (o por caja). Se tipifican los servidores según su sistema
operativo y capacidad para fijar un precio por cada uno de ellos. Es un modelo
poco preciso, pero sencillo y fácil de contrastar con los inventarios. Por ello se
utiliza mucho en los contratos de outsourcing completos. En el precio se distin-
gue entre los servidores que se compran y entre los que sólo se administran.
• Coste por capacidad de proceso asignada. En los nuevos entornos virtua-
lizados, un servidor alberga varias máquinas virtuales, por lo cual la capaci-
dad de proceso asignada es una medida algo más precisa que la medición por
servidores físicos.
• Coste por unidad de almacenamiento. En relación al almacenamiento, se
miden los “gigas” (GB) o los “teras” (TB) netos totales instalados o los asig-
nados a un cliente para cada servicio.
Aunque ninguno de estos modelos para la imputación de los consumos es muy pre-
ciso, su contabilización mensual resulta sencilla.
Una vez calculado el coste de la provisión y prestación del servicio, se pueden apli-
car distintas formulas de facturación:
• Precios fijos o tarifa plana. El precio mensual es constante, con indepen-
dencia del consumo.
• Precios con dos tramos. La cual incluye un término fijo para cubrir los cos-
tes fijos y un término variable en función del consumo que recuperaría los
costes variables.
• Precios alineados con el mercado. Los precios se regulan por el propio
mercado o por benchmarking externos.
En cualquier caso, el modelo de facturación debe ser sencillo y entendible por las
partes. Para la fijación del precio se pueden seguir varias tendencias: la más utili-
zada para servicios internos es cuando los precios se basan en el coste real de los
servicios; otra es el establecimiento del precio según la demanda que exista del
mismo o según la exclusividad del servicio ofertado.
En los primeros años o ejercicios en que se aplique la facturación, se deben revisar
las tendencias del consumo de los clientes y usuarios para evitar que las estruc-
turas de precios estén generando distorsiones en el consumo óptimo de los servi-
cios de TI.
Supervisión del funcionamiento del propio proceso

Su objetivo es medir y revisar el cumplimiento de los objetivos del proceso. Se debe
comprobar que se realiza el seguimiento del presupuesto y sus cierres, que no se
ejecutan compras sin la autorización de este proceso, que se contabilizan todos los
costes con el detalle definido, que se realiza la facturación, etc.
En este proceso es especialmente importante establecer un programa de auditorías
y revisiones del cumplimiento de los requisitos legales y la normativa interna.
Como gran parte de la actividad del proceso la realizarán las áreas económicas de la
empresa, las auditorías y las revisiones deberían ser conjuntas.
Las revisiones, evaluaciones y auditorías del proceso se deben registrar, junto con
las conclusiones obtenidas, las acciones correctivas identificadas y las comunicacio-
nes realizadas a las partes correspondientes.
Mejora del proceso de gestión financiera de TI

Al igual que el resto de los procesos, se debe tener en cuenta la actividad de
mejora continua: monitorizar, informar, dirigir la calidad y cumplimiento de lo
establecido, comunicar resultados y establecer las mejoras que se deben realizar.
Es importante velar por que el control económico necesario no genere una
burocracia innecesaria. Se tienen que analizar los atrasos e ineficiencias que
genera el propio proceso para ir implementando medidas correctoras. La auto-
rización de partidas por bloques a las áreas de TI puede ser una forma de agili-
zar las actividades, delegando el control detallado de las pequeñas partidas de
gasto.
Estas mejoras se incorporarán, para su tratamiento y aprobación, en el plan unifi-
cado de mejora de la gestión del servicio (véase el capítulo 4) y deberán coordi-
narse con el área financiera de TI.
Roles participantes en la gestión financiera de TI

Como en el resto de los procesos, los roles intervinientes en este proceso se estruc-
turan en: los roles propios del proceso y los roles ajenos al mismo. En una organi-
zación interna de TI se pueden simplificar mucho, pero la situación cambia si la
empresa se dedica a la comercialización de servicios de TI, en cuyo caso es necesa-
rio desarrollar mucho más los roles expuestos a continuación.
• El gestor financiero de TI es el responsable de que la actividad del proceso se
lleve a cabo: dialoga con el área financiera de la empresa, elabora los presu-
puestos, realiza su seguimiento, supervisa la contabilización del gasto de TI,
supervisa la facturación, etc.
• Los administradores o personal de soporte al proceso ayudan al titular del
proceso en el control de toda la actividad.
• El área o departamento económico-financiero de la empresa realiza muchas
de las actividades de gestión presupuestaria, contabilidad y facturación del
proceso. En esta área destaca el rol del contable que realiza la contabilización
del gasto de TI, al igual que para el resto de áreas de la empresa.

cumplan los niveles pactados, incluido el económico.
• El propietario del modelo de gestión de TI (SGSTI), que actúa como pro-

pietario del proceso (process owner), define el proceso y vela por el cumpli-
miento de sus actividades, y se encarga de la mejora continua del mismo.
Todo ello, de una forma integrada con el modelo de gestión de TI incorpo-
rado en el SGSTI.
• El comité de cambios (CAB), que aprobará los cambios, con su correspon-
diente coste económico asociado.
• El gestor de la capacidad, que proporciona la información del consumo téc-
nico de los recursos, necesaria para las previsiones presupuestarias y para la
facturación a los clientes.
• El gestor de las relaciones con el negocio, que trata con las áreas cliente los
presupuestos para su área, los costes de los servicios y el detalle de las factu-
raciones.
Roles del proceso
OTROS PROCESOS PROCESO DE GESTIÓN

FINANCIERA DE TI
Responsable de la Comité de cambios

gestión del servicio (CAB)
SGSTI Gestor financiero

de TI
Administrador y
soporte del proceso
Propietario del
Gestor de la
modelo (SGSTI)
capacidad
Gestor de las
relaciones con Departamento financiero
de la empresa Contables de
el negocio la empresa
Figura 6.4.10. Roles del proceso de gestión financiera de TI

• El personal de TI, que imputa su dedicación a las diversas tareas con el fin
de tener una contabilización detallada de los servicios.
• Las diversas áreas de TI, que realizan las peticiones de compra.
En la figura 6.4.10 se muestran los roles principales relacionados con el proceso.
Métricas
Las métricas se deben adaptar a las necesidades de gestión y control que tenga cada
organización. Las métricas de gestión financiera de TI suelen proporcionar infor-
mación sobre los costes, en forma de ratios, y medidas específicas sobre el funcio-
namiento del proceso:
• Ratios sobre presupuestos y costes:
– Presupuesto de TI en relación al volumen de facturación de la empresa
(ITR, IT Spending per unit of Revenue). Representa el porcentaje de los
ingresos de la empresa que deben destinarse a sostener las tecnologías de
la información en la empresa.
– Peso del presupuesto de inversión (CAPEX) en relación al presupuesto
total de TI.
– Ratio de coste total de TI por usuario.
– Ratio de coste total de TI por potencia de proceso instalada (MIP, MIP
equivalente, specs, transacciones por minuto, etc.)
– Ratio de coste total de TI por GB almacenamiento instalado.
– Con frecuencia se miden ratios de costes sobre áreas o temáticas de interés
en un período dado, como por ejemplo, el porcentaje de presupuesto dedi-
cado a seguridad informática, presupuesto dedicado a innovación, etc.
• Métricas sobre el proceso:

– Porcentaje de los servicios que tienen los costes conocidos en detalle.
– Porcentaje de desviación o del cumplimiento en presupuesto.
El ITR es el ratio más utilizado y más importante, pues refleja el coste de TI

en relación al volumen de la facturación del negocio. Dependiendo del sector
de negocio, este indicador suele oscilar entre el 3% y 8% según las necesidades
tecnológicas de la empresa 3. En la figura 6.4.11 se muestran algunas de las princi-

pales métricas de la gestión financiera de TI.
de itSMF España
Adicionalmente, también se pueden utilizar otro tipo de indicadores económicos

dependiendo del análisis que se quiera realizar, como por ejemplo:
• Inversión de TI frente a la inversión de la empresa (CAPEX TI/Presupuesto
de inversión de la empresa).
• Gasto operativo de TI frente al presupuesto de TI (OPEX TI/Presupuesto
de TI).
• Coste de los recursos humanos de TI frente al presupuesto total de TI.
Resumen
El crecimiento de los recursos dedicados a los sistemas de información y la utili-
zación extensiva de los servicios de TI, junto con la tendencia a la reducción de
3
El límite inferior del ITR puede llegar al 1%, como es el caso del sector de distribución.
presupuestos asignados, provoca la necesidad imperiosa de una gestión financiera en

TI más avanzada que posibilite una adecuación de los costes y las inversiones a los
presupuestos disponibles, para ser capaces de satisfacer las necesidades del negocio.
En la actualidad, los proveedores de servicios de TI reciben presiones desde dife-
rentes puntos para que reduzcan sus costes. Pero al mismo tiempo se les pide que
mantengan e incluso mejoren los servicios y, todo ello, en un entorno tecnológico
cada vez más complejo. La ausencia frecuente de una gestión financiera en TI trans-
parente y en lenguaje del negocio, provoca que, mientras la dirección recorta los
presupuestos de TI, las áreas cliente continúen realizando unas demandas irreales e
injustificables en este nuevo escenario.
La gestión financiera de los servicios de TI es aplicable tanto a organizaciones de
TI internas como a proveedores de servicios al mercado. Se articula en torno a tres
grandes actividades: presupuestar, contabilizar y facturar.
• La elaboración de los presupuestos permite controlar y predecir el gasto eco-
nómico mediante un ciclo de negociaciones periódicas, que permiten su con-
fección, publicación y seguimiento.
• La contabilidad de TI realiza el registro en las cuentas del gasto del dinero,
haciendo énfasis en la identificación de los costes por servicio, cliente y por
actividad.
• La facturación de los servicios de TI, actividad opcional en ISO/IEC 20000,
permite trasladar a los clientes, de forma real o informativa, el coste ocasio-
nado por los servicios prestados, de esta forma se influye en la demanda y
grado de utilización de los servicios.
Otro objetivo del proceso es la integración plena con los departamentos financie-
ros y contables de la empresa evitando mantener registros paralelos. Pero estos sis-
temas de la empresa se deben adaptar para satisfacer también las necesidades de
información analítica de TI.
Beneficios
El principal beneficio es una gestión más eficiente y controlada de los gastos en tec-
nologías de la información.
La presupuestación es la actividad clave en el proceso de gestión financiera de los
servicios de TI y proporciona:
• Mejora en la priorización de los proyectos de inversión. Toma de decisiones
sobre los servicios en base a análisis de rentabilidad de las inversiones.
• Mayor agilidad en la realización y ejecución del presupuesto.

• Mejora en la planificación de las compras, consiguiendo una mejora en los
precios de adquisición.
• Minimiza los desvíos en las estimaciones establecidas, proporcionando una
organización de TI más predecible en sus costes para el negocio.
Los principales beneficios de la contabilidad de los costes en los servicios de TI son:

• Proporciona información detallada de los costes incurridos, para el análisis
de ineficiencias, y la optimización de la capacidad y la disponibilidad de los
servicios.
• Mejora la precisión de las predicciones presupuestarias futuras.
• Pasa a términos económicos la infrautilización o sobreutilización de las
infraestructuras.
• Facilita información sobre el coste de cada servicio, de cada cliente y de
las principales actividades.
Los principales beneficios de un proceso adecuado de facturación son:

• Uso eficiente de los servicios de TI por parte de los clientes y usuarios.
• Crear una consciencia en los clientes del coste incurrido por la organización
de TI en la prestación de servicios de TI.
• Moderación de la demanda por parte de los clientes y del consumo por parte
de los usuarios, al conocer los costes y pagar, si procede, por ellos.
• Reducción del TCO de los servicios debido al conocimiento y control de sus
estructuras de coste.
• Disponibilidad de los precios como herramienta a utilizar en la gestión de la
demanda.
• Recuperación del coste incurrido en TI mediante los pagos de los clientes,
en caso de que la estrategia corporativa no marque TI como un centro de
coste.
Quizá el beneficio más relevante es el de proporcionar el nexo de unión entre la

organización de TI y el negocio mediante parámetros objetivos y mesurables, que
contribuyen a lograr el equilibrio entre ambos, evitando que la organización de TI
se separe demasiado de las necesidades reales del negocio y que los negocios
demanden servicios no justificables en términos de coste/beneficio.
• ¿Cuáles de las tres actividades principales de este proceso (presupues-
tar, contabilizar y facturar) se realizan en su organización?
• Indique tres procesos que son necesarios tener implantados previa-
mente para que el proceso de gestión financiera de TI tenga éxito.
4
6.5. Gestión de la capacidad 369
6.5. Gestión de la capacidad
Figura 6.5.1. Esquema general del proceso de gestión de la capacidad
La actividad del negocio no debería ser coartada por una falta de capacidad o un mal
rendimiento de los sistemas de información. En momentos de máxima demanda
los sistemas deben responder. Los incrementos de carga deben estar previstos, los
sistemas diseñados para absorberlos y también lo deben estar para poder crecer
de forma dinámica. Pero alcanzar este estatus de poderío no es una tarea sencilla.
Se requiere la ejecución de un conjunto complejo y diverso de actividades. En este
proceso se explican las más relevantes que están contenidas en las mejores prácticas
del mercado (véase la figura 6.5.1).
El proceso de gestión de capacidad, muy maduro en la década de 1980 con los
entornos mainframe, pasó al olvido a comienzos de la década de 1990 con la lle-
gada de los sistemas abiertos; cuando duplicar la capacidad de un equipo era más
económico que pagar a un ingeniero de sistemas para que la planificara. Pero las
alegrías y derroches en TI finalizaron con la burbuja de las “puntocom”. Se ha
vuelto a la senda del estricto control económico y al seguimiento del retorno de
la inversión. Así, la gestión de la capacidad vuelve a tener plena vigencia en los
comienzos del siglo XXI.
Como si los ajustes económicos no hubieran sido justificación suficiente, las ten-
dencias a la consolidación y a la virtualización de las infraestructuras refuerzan la
necesidad de disponer de una buena gestión de la capacidad (y rendimiento).
Implantar plataformas comunes requiere gestionar y controlar los recursos que
consume cada servicio para evitar que interfiera en el rendimiento de sus compañe-
ros de habitáculo.
Recientemente se ha incorporado a la ecuación la necesidad de ajustar el consumo
eléctrico, como consecuencia de los problemas con la refrigeración de los centros
de datos, la reducción del impacto ambiental de las TI y la necesidad de rebajar la
factura eléctrica. Este recién llegado sitúa también a la gestión de la capacidad
como un buen instrumento para ejecutar las políticas medioambientales, o verdes,
en TI relativas al uso eficiente de las infraestructuras.
Gestionar la capacidad de los servicios de TI permite garantizar que se tendrá, en
todo momento, la capacidad suficiente para cubrir la demanda actual y futura acor-
dada con el negocio, manteniendo siempre un coste razonable y equiparable con el
mercado. La gestión de la capacidad debe equilibrar las previsiones de utilización o
carga con los recursos disponibles, de modo que se eviten pérdidas o degradacio-
nes del servicio. Pero también debe vigilar el coste de la sobrecapacidad para evitar
el derroche de recursos.
Gestionar adecuadamente la capacidad no es una tarea fácil. Se debe tener un cono-
cimiento técnico de las infraestructuras de TI, pues se encarga de supervisar la capa-
cidad actual, de anticipar las ampliaciones necesarias, de modelar el comporta-
miento de las aplicaciones, y del ajuste y mejora continua del rendimiento.
Además, requiere un entendimiento de la actividad del negocio, para poder predecir
las variaciones en el consumo de recursos (crecimiento “vegetativo”, campañas de
marketing, variaciones estacionales, acontecimientos singulares, etc.). La gestión de la
capacidad debe conocer las variaciones temporales del negocio para ajustar los recur-
sos, como es típico en la facturación mensual. Según el ciclo del negocio, se pueden
presentar campañas según la estación del año. Así, en las empresas de telefonía móvil,
las épocas de fin de año y de verano se dispara la actividad de los consumidores y los
sistemas se ven sometidos a su máxima carga. También hay que tener en cuenta acon-
tecimientos puntuales, como el lanzamiento de una campaña de marketing. Por todo
ello, es necesaria una comunicación fluida entre la gestión de la capacidad y el negocio.
En la figura 6.5.2 se presenta una visión introductoria al proceso de gestión de la
capacidad.
El objetivo del proceso de gestión de la capacidad es garantizar que siempre existe
la capacidad de TI necesaria, justificable en términos de coste, y ajustada a las nece-
sidades del negocio, actuales y futuras.

capacidad • Conocimiento de la evolución de
actividad del negocio en su relación
con la utilización de las TI.
Definición:
• Gestión adecuada de la capacidad
Procesos que velan por que los servicios existente, evitando las carencias y
tengan en todo momento la capacidad también los excesos.
necesaria y trabajen con un rendimiento • Un rendimiento optimizado.
óptimo.
• Garantía de que los servicios cumplen
con la capacidad requerida en cada
momento.
Objetivo:
• Ahorro de costes, al tener los
Asegurar que el proveedor del servicio recursos ajustados a las necesidades.
tiene, en todo momento, la capacidad • Prepara un plan de capacidad de TI.
suficiente para cubrir la demanda
• Predicciones continuas y periódicas
acordada, actual y futura, de las
basadas en datos de negocio y de la
necesidades del negocio del cliente.
tecnología.
• Minimiza las incidencias por falta de
capacidad.
Figura 6.5.2. Introducción al proceso de gestión de la capacidad
El proceso de gestión de la capacidad debe ser el foco central de todos los temas
relacionados, tanto con la capacidad como con el rendimiento. Las tareas diarias
deberán realizarse por los grupos técnicos de la organización (técnica de sistemas,
administración de bases de datos, ingeniería, soporte de redes, etc.), trabajando
para este proceso en las actividades que marca la gestión de la capacidad.
La gestión de la capacidad trata aspectos proactivos y reactivos.
• La faceta proactiva comprende todas las actividades que permiten anticiparse
a una carencia de capacidad y a un escaso rendimiento, como por ejemplo, la
previsión de la demanda por parte del negocio, la previsión de la capacidad
necesaria por los servicios, el modelado de servicios, el dimensionado de las
aplicaciones, el plan de capacidad, etc.
• Los aspectos reactivos del proceso están relacionados con la detección de faltas
de capacidad, el ajuste o tuning de componentes o de los servicios, la provisión
con urgencia de soluciones, el establecimiento de umbrales en la monitoriza-
ción, etc.
En ITIL v2 y v3, la gestión de la capacidad se estructura en tres áreas: gestión de la

capacidad del negocio, de los servicios y de los recursos. Como en las Normas
ISO/IEC 20000 no se establece nada al respecto, en este libro se ha decidido seguir
el mismo esquema de ITIL por considerarlo un enfoque muy amplio que abarca
desde una visión del negocio, hasta el detalle técnico de los recursos.
Siguiendo con el alcance dado en ITIL, el ámbito de la gestión de la capacidad
comprende todos los aspectos necesarios para que los servicios estén operativos con
el rendimiento pactado, como por ejemplo:
• El seguimiento y monitorización de la capacidad y rendimiento de los servi-
cios y de la infraestructura:
– Los servidores, almacenamiento, redes, etc.
– Las unidades de soporte. La capacidad de ejecución de los recursos huma-
nos, propios o de servicios subcontratados. Únicamente en lo relativo a su
participación en el soporte de los servicios de TI.
– Las aplicaciones.
– Las instalaciones, climatización y suministro eléctrico.
– Los proveedores y cómo se contempla la variación de capacidad en sus con-
tratos (de forma coordinada con el proceso de gestión de suministradores).
– Revisión de equipamiento y aplicaciones sin utilizar.
• La ejecución de mejoras que conlleve la utilización más eficiente de los recur-

sos existentes.
• La realización de previsiones sobre la demanda y utilización de los recursos
de TI.
• La influencia en la demanda de los recursos, con el apoyo de la gestión finan-
ciera.
• Generación del plan de capacidad y las sucesivas actualizaciones.
El proceso de gestión de la capacidad también gestiona la obsolescencia de los equi-

pos y los servicios, realiza la evaluación de los efectos sobre la capacidad que pue-
den producir los cambios y trabaja en la identificación del impacto de las nuevas
tecnologías.
Igualmente, debe tener en cuenta el impacto de la evolución del entorno exterior
de la empresa, como por ejemplo, cambios legislativos, cambios sociales que afec-
ten en la demanda en TI, etc.
Además, el proceso debería tratar otros aspectos relacionados con la mejora o inno-
vación en las plataformas informáticas, como por ejemplo:
• La automatización de la provisión de peticiones de los usuarios, autorregis-
tro, autorresolución, distribución de software, etc.
• La automatización de los centros de datos, con la implantación de políticas
de asignación dinámica de recursos según las previsiones de carga, provisión
automatizada de infraestructura virtual, etc.
• La consolidación de servidores y del almacenamiento.
• La virtualización de los sistemas operativos.
• La gestión de la obsolescencia del equipamiento y la renovación del parque.
La desconexión y retirada de equipos. La gestión del apagado de aplicacio-
nes sin uso.
• En coordinación con las políticas medioambientales en TI (green IT), parti-
cipa en la implantación de las políticas relacionadas con el consumo energé-
tico y de materiales menos contaminantes, como por ejemplo:
– El seguimiento del consumo eléctrico. Implantación de políticas de reduc-
ción del consumo en equipos, como la entrada en suspensión tras perío-
dos de inactividad.
– La definición de políticas de compra de equipamiento certificado con eti-
quetas verdes de bajo consumo y materiales reciclables.
Una correcta gestión de la capacidad permitirá no sólo reducir las incidencias y

degradaciones del servicio por falta de recursos, sino que anticipa las necesidades
permitiendo a la organización de TI trabajar con menos presión y con costes más
ajustados. En la figura 6.5.3 se muestran los principios básicos que se deben tener
en cuenta al implementar el proceso.
Un entendimiento del negocio y de la evolución del mercado es esencial para el
diagnóstico de la variación de la demanda en la utilización de los recursos de TI. El
contacto con el negocio se debe llevar a cabo manteniendo un diálogo continuo
con las unidades clientes, apoyándose en la gestión de relaciones con el negocio.
Así, el contacto entre TI y los clientes está coordinado. La gestión de la capacidad
tiene que entender la estrategia a largo plazo del negocio al tiempo que propor-
ciona información sobre las últimas ideas, tendencias y tecnologías que desarrollan
los proveedores de hardware y software.
El conocimiento técnico de las infraestructuras tecnológicas es necesario para realizar
una adecuada monitorización de la capacidad y una gestión técnica de la capacidad
de los recursos. Debe conocer el potencial de la tecnología y aprovechar las innova-

ciones para asegurar que los servicios de TI se adaptan a las expectativas cambian-
tes del negocio. La gestión de la capacidad debe promocionar que los avances tec-
nológicos se incorporen al diseño de los sistemas con el fin de facilitar la
flexibilidad de las infraestructuras y acortar los tiempos de provisión de nuevas
capacidades. Destacan la consolidación y virtualización de los servidores y del alma-
cenamiento, como nuevos principios que se deben tener en cuenta en la arquitec-
tura tecnológica de los sistemas. La automatización de la provisión de recursos
siguiendo unas políticas predefinidas, permitirá asignar dinámicamente los recur-
sos a los servicios según se necesiten. Otras estrategias son la compra de infraes-
tructura con capacidad preinstalada que se puede activar por software cuando se
necesita (capacidad bajo demanda), los blade servers con una gestión conjunta como
pool de servidores, etc.
La previsión de la evolución de la demanda y de la tecnología permitirá a TI ir por
delante de las crisis internas y gestionar las necesidades con el plazo necesario. En
el ámbito de la previsión y anticipación, se utiliza el plan de capacidad como el ins-
trumento formal más importante de este proceso.
Previsión
Utilización de la carga
o carga
Capacidad Plan de
Previsiones
del negocio Modelos capacidad de capacidad
Dimensionados Informes sobre

CDB recursos y
servicios
Base de datos
de capacidad Informes de
excepciones
Capacidad de
los servicios • Datos de negocio
• Datos del servicio
• Datos técnicos
• Datos financieros
• Datos de utilización
Capacidad de Umbrales utilización Monitorización

los recursos Umbrales de SLA de la capacidad Ajuste o tuning
Figura 6.5.4. Componentes principales del proceso de gestión de la capacidad
Los principales componentes del proceso son:

Ajuste o tuning. Optimización de los sistemas con respecto de la carga actual o
prevista de acuerdo con el resultado del análisis de la información de rendimiento
de los servicios.
Base de datos de gestión de la capacidad (CDB, Capacity Data Base). La base de
datos de gestión de la capacidad centraliza los datos y el conocimiento de este pro-
ceso. Es un repositorio en el que se almacenan información de negocio, de servicio,
técnica, financiera, de utilización, etc. Las actividades de la gestión de la capacidad
almacenan y utilizan los datos contenidos en la CDB. Normalmente, la CDB no
será una única base de datos, sino que es un concepto lógico que recopila datos,
ficheros de log, informes, documentos, etc.
Carga, utilización o demanda operacional. Consumo o utilización de los recur-
sos por parte de los clientes y usuarios. Se utiliza como entrada para el dimensiona-
miento y en la definición de políticas de utilización. Conviene no confundir este
término (demanda operacional) con el concepto de la gestión de la demanda utili-

zado en el libro Estrategia del Servicio de ITIL v3 (demanda estratégica), que se
centra en gestionar las peticiones (demandas) de nuevos servicios realizadas por el
negocio hacia TI; mientras que la carga o utilización tratan con las previsiones de
uso o trabajo real que ejecutan los servicios.
Dimensionado. Estimación de la capacidad que necesitará un servicio, una aplica-
ción o un recurso cuando entre en el entorno productivo. Se contemplan varios
escenarios de evolución de la carga de trabajo. Se suele realizar en la fase de diseño
(normalmente sobre los críticos) o en cambios importantes.
Gestión de la capacidad del negocio. Subproceso que se encarga de garantizar
que se consideran, planifican e implementan los requisitos de capacidad y rendi-
miento del negocio para los servicios de TI.
Gestión de la capacidad de los servicios. Subproceso que se centra en la gestión
de la capacidad y el rendimiento de los servicios de TI. Se encarga de garantizar el
cumplimiento de estos aspectos especificados en los acuerdos del nivel de servicio.
Gestión de la capacidad de los recursos. Subproceso que se encarga de la gestión
de la capacidad y el rendimiento de todos los componentes contenidos en la
infraestructura de TI.
Informe sobre los recursos y los servicios. Muestra el comportamiento en
cuanto a capacidad y rendimiento de los recursos y servicios. Refleja el grado de
ocupación o de saturación de los mismos.
Informe de excepciones. Pone foco en situaciones de incumplimiento de los nive-
les de servicio o de saturación de la capacidad de los recursos o servicios. Analiza
las causas y proponen soluciones.
Modelado. Predicciones del comportamiento de los servicios frente a variaciones
previsibles de la carga de trabajo. Las principales técnicas de modelado son el análi-
sis de tendencias de consumo, el modelado analítico o matemático, las simulacio-
nes ante variaciones de carga, etc. En el mejor de los casos, los modelos se calculan
de forma empírica sobre una instalación piloto. Los modelos deben ser sencillos y
estar representados en forma de tabla de valores o de gráfica.
Monitorización. Es la medición de la capacidad, rendimiento y utilización de cada
servicio y recurso de manera continuada. La monitorización utiliza como entradas
los umbrales de utilización de recursos y los umbrales establecidos en los acuerdos
de nivel de servicio y en las políticas tecnológicas.
Previsión de la carga. Actividad que consiste en pronosticar la carga o utilización
de los recursos informáticos.
Previsión de la capacidad. Estimaciones sobre la capacidad necesaria en el futuro

de los componentes y servicios. Se realiza a partir de la experiencia histórica y de la
base de datos de capacidad. Las previsiones se incorporan en el plan de capacidad.
Plan de capacidad. Es el documento sobre el que se articula la dotación de recur-
sos en TI. Describe los niveles actuales de utilización de recursos y de rendimiento
de los servicios, y estudia los planes y estrategia de negocio para predecir los recur-
sos futuros necesarios para los servicios de TI.

El proceso de gestión de la capacidad carece de un gran flujo predefinido que aglu-
tine a la mayoría de sus actividades, sino que éstas se desencadenan por eventos dis-
cretos, unas veces por que se alcanzan las fechas para la realización de un informe o
del plan de capacidad, otras por una alarma de falta de rendimiento, por la llegada
de un nuevo servicio que requerirá dimensionarlo, porque antes del paso a explota-
ción habrá que comprobar el consumo de recursos y el rendimiento de las nuevas
aplicaciones, etc.
En el proceso, únicamente existe un pequeño flujo, denominado ciclo de mejora de
la capacidad, que revisa de forma continua y permanente la capacidad y el rendi-
miento.
Este proceso requiere profundos conocimientos técnicos, tanto en el ámbito del
desarrollo, como en la gestión de las infraestructuras, especialmente en las activida-
des de ajuste o tunning. Conviene tener presente que el proceso gestiona tanto la
capacidad de los sistemas como su rendimiento. Ambos aspectos influyen directa-
mente en la disponibilidad y tiempo de respuesta de los servicios. Por ello, el pro-
ceso está muy vinculado a la gestión de la disponibilidad.
A pesar de no tener una secuencia encadenada de acciones, el proceso tiene unas
entradas, unas actividades y unas salidas. Tradicionalmente, en ITIL, las activida-
des del proceso se estructuran en forma matricial. Primero se contemplan los tres
grandes subprocesos: la gestión de la capacidad del negocio, de los servicios y de
los recursos para describir, posteriormente, un conjunto de actividades que se reali-
zan en cada uno de estos ámbitos: elaborar el plan de capacidad, ciclo de mejora de
la capacidad, etc. En la figura 6.5.5 se muestra un esquema de ellas.
Las entradas que desencadenan el inicio de alguna actividad en el proceso son la
proximidad de la fecha para iniciar la revisión del plan de capacidad (normalmente
de forma trimestral y como mínimo anual); la activación de una alarma sobre capa-
cidad o rendimiento, que requiere actuación antes de que se produzca un incidente;
Desencadenantes Gestión capacidad del negocio. Salidas principales:

del proceso: Ü Plan de capacidad.
Gestión capacidad de servicios.
Ü Fecha preparación del Ü CDB.
Gestión capacidad de recursos.
plan de capacidad o
Ü Informes capacidad.
de informes. x x x Elaborar el plan de capacidad.
Ü Dimensionado de
ÜAlarma de capacidad o x x x Ciclo de mejora de la aplicaciones.
rendimiento. capacidad y rendimiento:
ÜProyectos desarrollo. • Monitorización. Salidas secundarias:
ÜVariaciones en los SLA. • Análisis. Ü Umbrales y alarmas.
ÜSolicitud de un informe • Ajuste o tunning. Ü Líneas base y perfiles.
de capacidad o
• Implementación. Ü Recomendaciones
rendimiento.
para SLA.
ÜCambio en la estrategia x Relacionarse con otros procesos. Ü Recomendaciones
o tecnología.
para políticas de
x Influir en la utilización.
Entradas de soporte: facturación.
Ü Estrategias del negocio x x Modelado. Ü Cambios proactivos.
y de TI.
x Dimensionado de aplicaciones. Ü Planificación
Ü SLR y SLA. operacional revisada.
x x x Realización de informes. Ü Propuesta de
Ü Incidentes y problemas
ocurridos. actividades para la
— — — Administrar la base de datos de
mejora de los servicios.
Ü CMDB y CDB anterior. capacidad (CDB).
Ü Lista de cambios.
x x x Supervisión y mejora del proceso.
Ü Presupuestos.
la llegada de un nuevo proyecto, de un nuevo desarrollo, de evolución de un servi-

cio existente o de cambio de las infraestructuras, que requieren el dimensionado de
recursos; nuevos acuerdos o variaciones a los acuerdos de nivel de servicio existen-
tes (SLA); solicitud por otra área de un informe de capacidad o rendimiento; un
cambio en la tecnología o en la estrategia tecnológica (por ejemplo, se inicia una
política de consolidación y de virtualización).
Las entradas que se utilizan en las actividades del proceso como soporte son la
estrategia de negocio para conocer las futuras variaciones de la demanda y la estra-
tegia de TI relacionada con la capacidad y rendimiento; los requerimientos de capa-
cidad demandados y los acuerdos de nivel de servicio pactados; los incidentes ocu-
rridos cuyo origen fue una falta de capacidad o de rendimiento, los problemas
abiertos o cerrados sobre este ámbito; la información obtenida sobre cualquier ele-
mento a partir de la base de datos de gestión de la configuración (CMDB, Change
Management Data Base) y la información sobre los históricos de monitorización en
la base de datos de gestión de la capacidad (CDB, Capacity Data Base); la planifica-
ción de los cambios a partir de la lista de cambios planificados (FSC, Forward Sche-
dule of Changes) o bien change schedule (siguiendo la terminología ITIL v3), para
conocer en qué momento se necesitará la capacidad; los presupuestos de TI que
establecen los recursos económicos disponibles; etc.
La gestión de la capacidad tiene tres subprocesos o ámbitos de actuación: el nego-
cio, los servicios y los recursos.
• La gestión de la capacidad del negocio. Se enfoca en conocer la capacidad
que va a demandar el negocio para anticiparse en la cobertura de las necesi-
dades. Los requisitos futuros se obtienen a partir de los planes de negocio,
crecimiento, planes de desarrollo, nuevos servicios, etc.
En la capacidad del negocio también se incluyen los aspectos de la capacidad
de los servicios en lo concerniente a su relación con otros procesos: asisten-
cia en la definición de los requisitos de nivel de servicio de capacidad, diseño
de nuevos servicios y la provisión de infraestructuras, verificación de SLA en
rendimiento y carga, firma de los acuerdos, etc.
• La gestión de la capacidad de los servicios. Se centra en la gestión de la
capacidad y rendimiento de los servicios de TI, que deben cumplir los míni-
mos establecidos en los acuerdos de nivel de servicio. Se puede considerar
como la visión hacia el interior de los servicios centrada, principalmente,
en conseguir su adecuado funcionamiento, ya que las interacciones con el
entorno se tratan en la capacidad del negocio.
• La gestión de la capacidad de los recursos. Se centra en la gestión de los
componentes individuales de la infraestructura de TI: capacidad, rendi-
miento, parametrización, optimización, monitorización, obsolescencia, etc.
Siguiendo ITIL, en cada uno de estos tres ámbitos se realiza un conjunto de activi-
dades que se enumeran de forma común, aunque unas son más específicas de un
ámbito y otras, en cambio, se realizan en los tres.
• Elaborar el plan de capacidad. Documento que recoge de forma precisa las
necesidades inmediatas y a medio plazo de recursos. Su elaboración orquesta
un movimiento en toda la organización para predecir las necesidades de
capacidad del negocio, de los servicios y de los recursos. Es el documento
maestro que pronostica las necesidades para que se proporcionen los presu-
puestos necesarios.
• Ciclo de mejora de la capacidad y rendimiento. Conjunto de 4 activida-

des encadenadas que permiten mejorar de forma permanente la capacidad y
el rendimiento de los servicios y de los componentes. Este ciclo debe estar
actuando de forma continua.
– Monitorización. Registro automatizado, mediante herramientas, de la
capacidad y el rendimiento de los recursos, de los servicios e, incluso, de
la actividad en el negocio (medida en este caso a través del uso de los
servicios).
– Análisis. Estudio de los resultados de la monitorización para detectar
mejoras.
– Ajuste o tunning. Identificación de las acciones correctoras que se deben
llevar a cabo en los recursos físicos con el fin de mejorar el rendimiento o
el uso de la capacidad.
– Implementación. Implantación de las mejoras identificadas (análisis o
ajuste), siempre bajo el proceso de gestión del cambio, generando las peti-
ciones de cambio (RFC, Request for Change) correspondientes.
• Relacionarse con otros procesos. La gestión de la capacidad interacciona

en temas de capacidad y rendimiento con muchos procesos. Da soporte a la
gestión de nivel de servicio (SLR, SLA y cumplimiento de niveles de servi-
cio), necesita de las relaciones con el negocio, establece requisitos, supervisa
las pruebas de gestión de la entrega, interactúa con la gestión financiera en la
elaboración del plan de capacidad, determina las compras necesarias, interac-
túa con la gestión del incidente y del problema para detectar las carencias en
la capacidad o rendimiento, etc.
• Influir en la utilización. Conjunto de acciones que permiten adecuar el uso
y la carga de trabajo de servicios y recursos generados por parte de las áreas
cliente y de los usuarios. En cierta manera gestiona la demanda, entendida
como utilización de los servicios. Se encarga de ejecutar las políticas de TI
en cuanto al uso.
• Modelado. Predicción o estimación de la actividad del negocio o del compor-
tamiento de los servicios bajo varios escenarios de carga. El modelado permi-
tirá predecir el rendimiento y el consumo de recursos. Presenta como resultado
tablas y gráficos que relacionan actividad, carga, capacidad o rendimiento.
• Dimensionado de aplicaciones. Cálculo de los recursos que necesitará una
aplicación para satisfacer los niveles de servicio. Se realiza bien al inicio del
proyecto (en el caso de aplicaciones bajo desarrollo o adquisición) o en la
fase de pruebas (en el caso de aplicaciones sujetas a mantenimiento). Tam-

bién se puede realizar en cambios importantes. Si se ha realizado el mode-
lado, se utilizarán sus resultados.
• Realización de informes de capacidad y rendimiento. Preparación y difu-
sión de informes diversos sobre la utilización de recursos (técnicos y huma-
nos), la capacidad remanente y el rendimiento de los sistemas. Los informes
se realizarán de forma periódica o bajo petición, en ambos casos coordina-
dos con el proceso de gestión de informes.
• Administrar la base de datos de capacidad (CDB). Diseño y creación de
la base de datos y administración posterior de la misma. La base de datos
contiene información histórica sobre la demanda y crecimiento del negocio,
sobre los servicios y sobre la capacidad de los elementos de configuración.
• Supervisión y mejora del proceso. Revisión continua del funcionamiento
del proceso y de sus actividades con el fin de detectar mejoras al mismo.
Las actividades de este proceso, con su participación en los ámbitos de negocio,

servicios y recursos, se muestran en la figura 6.5.6.
Actividades
Elaborar Ciclo de mejora Relacionarse
el plan de de la capacidad con otros
Subprocesos capacidad y rendimiento procesos
Modelado
Gestión capacidad Monitorización

del negocio
Realización
de informes
Análisis
Gestión capacidad Influir en la
de los servicios utilización Dimensionado
Ajuste aplicaciones
Gestión capacidad Implementación

de los recursos
Administrar la base de datos de capacidad

CDB
Supervisión y mejora del proceso
Fuente: Libro ITIL Provisión de Servicio publicado por OGC y e.p.
Figura 6.5.6. Actividades de la gestión de la capacidad

Las principales salidas o resultados del proceso son: el plan de capacidad elaborado o
actualizado, con las previsiones de recursos necesarias; la base de datos de capacidad,
con toda la información de capacidad y rendimiento recogida en la monitorización;
los informes de capacidad elaborados; y el dimensionado de aplicaciones realizado.
Como resultados secundarios del proceso se obtienen: los umbrales y alarmas para
la monitorización de la capacidad y rendimiento; las líneas base en cuanto a la utili-
zación de recursos y los perfiles de comportamiento; las recomendaciones de par-
tida para los acuerdos de nivel de servicio; las recomendaciones sobre políticas de
facturación, de cara a influir en el consumo de recursos; los cambios proactivos (y
sus RFC) para la mejora de la capacidad y del rendimiento; la planificación de las
operaciones revisada, de cara a ajustar los picos en la carga de los recursos; las pro-
puestas de actividades para la mejora de los servicios; etc.
El plan de capacidad
Uno de los principales instrumentos del proceso es el plan de capacidad, cuyo obje-
tivo es predecir las necesidades de capacidad con el fin anticiparse a su demanda.
Alrededor de la elaboración del plan se desencadena la actualización de informa-
ción y revisión completa de la situación actual. Las actualizaciones del plan marcan
el tempo de este proceso. Al igual que ocurriera en disponibilidad y continuidad, el
plan de capacidad marca el ciclo vital del proceso, que debe ir acompasado con la
gestión financiera de TI.
En el plan de capacidad también se incorporan los niveles actuales de utilización de
recursos y el rendimiento de los servicios. Se estudian los planes y la estrategia del
negocio. Las estimaciones y suposiciones realizadas se deben indicar con claridad.
También debería incluir recomendaciones sobre los recursos requeridos, sus costes,
los beneficios, el impacto, etc.
Las Normas ISO/IEC 20000 explicitan un conjunto de requerimientos que se
deben cumplir a través del plan de capacidad:
UNE-ISO/IEC 20000-1
La gestión de la capacidad debe elaborar y mantener un plan de capacidad.

La gestión de la capacidad debe estar dirigida a las necesidades del negocio y debe
incluir:
a) los requisitos de capacidad, rendimiento y comportamiento, actuales y previstos;
b) la identificación de plazos, umbrales y costes para las actualizaciones del servicio;
c) la evaluación de los efectos sobre la capacidad de actualizaciones anticipa-

das del servicio, peticiones de cambio, y nuevas tecnologías y técnicas;
d) la previsión del impacto de cambios externos, por ejemplo cambios legislativos;
e) los datos y los procesos para poder realizar análisis predictivos.
UNE-ISO/IEC 20000-2
Se debería generar un plan de capacidad mentar las opciones existentes junto con
donde se documente el rendimiento real su coste para cumplir con los requisitos
de la infraestructura y los requisitos espe- del negocio, así como, las soluciones
rados, con la frecuencia suficiente para recomendadas para conseguir los obje-
tener en cuenta el ritmo de cambios de los tivos de nivel de servicio tal como están
servicios y de los volúmenes de servicio, la definidos en el SLA.
información de los informes de gestión del
Debería existir una buena comprensión
cambio y del negocio del cliente.
de la infraestructura técnica y sus capa-
Dicho informe debería elaborarse al cidades presentes y las que estén pro-
menos anualmente. Se deberían docu- yectadas.
El plan de capacidad debe publicarse anualmente y debe estar alineado con el ciclo
presupuestario. Hay que tener presente que está muy vinculado al plan de inver-
sión y debe estar finalizado antes de que se inicie la elaboración de los presupuestos
de TI. Se recomienda su actualización cada tres meses, para reflejar los cambios en
el negocio o para corregir las previsiones.
En la figura 6.5.7 se muestra la estructura propuesta en ITIL, que divide el plan en
11 apartados.
Los apartados de mayor interés del plan de capacidad son:
• Los escenarios del negocio. Que analizan la situación actual del negocio,
visto desde la demanda hacia TI. Se presenta la situación actual del negocio
(número de departamentos, número de usuarios, número de edificios, volu-
men de transacciones, etc.). A partir de la estrategia y planes del negocio, se
realiza una previsión sobre la evolución del negocio, en cuanto a la actividad
prevista, nueva actividad, nuevos edificios, etc. Contemplando siempre las
repercusión que tendrán en los servicios de TI.
• El resumen de los servicios. Presenta la situación actual de los servicios, mos-
trando servicio a servicio un perfil del mismo: carga, tráfico, almacenamiento,
Plan de capacidad
Resumen de los servicios: 1. Introducción.

• Perfil de cada uno de 2. Resumen ejecutivo. Escenarios de negocio:
los servicios ofrecidos.
3. Escenarios del negocio: • Situación actual del negocio
• Incluyendo ratios de tráfico y previsiones de evolución,
y utilización de los recursos. • Situación actual del negocio. en cuanto a la actividad,
• Detalles de los nuevos • Evolución prevista. diversificación, etc.
servicios planeados.
4. Objetivo y alcance.
• Crecimiento o reducción
en la utilización de sistemas. 5. Métodos. Resumen de los recursos:
• Informe sobre la retirada • Utilización de recursos actual.
de sistemas. 6. Hipótesis.
• Tendencias de utilización
7. Resumen de los servicios: de recursos a corto medio
• Situación actual servicios. y largo plazo desglosadas
por plataformas.
• Previsiones servicios.
• Previsiones de recursos.
8. Resumen de los recursos: Estudio del impacto de los
nuevos escenarios de negocio
• Situación actual recursos.
descritos en el plan.
• Previsiones recursos.
Opciones de mejora: 9. Opciones de mejora de los
Presión de costes:
• Posibles opciones de servicios.
mejora de la eficacia • Descripción de los costes
y/o eficiencia (por ejemplo, 10. Previsión de costes. de las opciones de mejora.
consolidación, virtualización, • Costes actuales de los servicios.
11. Recomendaciones.
renovación, etc.). • Costes previstos.
Fuente: Libro ITIL Diseño del Servicio publicado por OGC y e.p.
Figura 6.5.7. Estructura del plan de capacidad propuesta en ITIL
procesamiento, etc. También se reflejan las tendencias de crecimiento “vegeta-

tivo” en la planta actual. El proceso de gestión de la capacidad recibe infor-
mación de los planes de negocio sobre la planificación de nuevos servicios o
sobre variaciones de uso correspondientes a servicios actuales. Con todo ello,
se realiza una previsión del crecimiento de los servicios a partir del escenario
de negocio previsto. Las previsiones van cuantificadas de tal forma que per-
mitan identificar las necesidades económicas asociadas: proyectos de inver-
sión, costes de soporte, costes de mantenimiento, etc.
• El resumen de los recursos. Realiza un resumen, a modo de inventario,
de los recursos actuales (hardware, software, aplicaciones, comunicaciones,
personal propio, personal ajeno, servicios, etc.). Analiza las tendencias de

variación a corto y medio plazo. A partir de las previsiones de los servicios se
realizan las previsiones de los recursos necesarios, de nuevo en todos sus
ámbitos (hardware, software, aplicaciones, RRHH, servicios externos, etc.).
• La previsión de costes. Con una visión más clara del destino del negocio,
con los servicios que serán necesarios mantener o crear, y con un inventario
de los recursos necesarios, se realiza la previsión de los costes. El objetivo de
este apartado es identificar las necesidades económicas para sostener y evolu-
cionar los servicios. Esta previsión servirá de entrada al plan financiero de
TI y se realizará de forma conjunta con el proceso de gestión financiera de TI.
La base de datos de gestión de la capacidad

(CDB, Capacity Data Base)
Si el plan de capacidad condensa en un documento la situación actual y las previ-
siones, la base de datos de la capacidad aloja todos los datos y la información nece-
saria para el trabajo en el proceso. Así, esta base de datos es un instrumento esen-
cial para el proceso. Se utiliza tanto para las actividades técnicas, como para la
generación de los informes de gestión y las previsiones.
La base de datos de gestión de la capacidad está formada por la información nece-
sitada por los tres subprocesos de gestión de la capacidad y por sus correspondien-
tes actividades. Es un concepto lógico, no tiene porqué ser una única base de datos
en el sentido estricto del término.
En la figura 6.5.8 se muestra una la estructura lógica que se deriva de ITIL para la
CDB.
La CDB se puede estructurar en 5 áreas (según ITIL):
• Datos del negocio. Contiene la información necesitada por el subproceso
de gestión de la capacidad del negocio para realizar las previsiones sobre el
negocio y su impacto sobre la capacidad necesaria y rendimiento de los ser-
vicios. La información más relevante puede ser: los procesos de negocio a
los que se da soporte por TI; la identificación de los edificios y emplaza-
mientos en los que se desarrolla el negocio; la distribución geográfica y fun-
cional de los usuarios de TI; los volúmenes de actividad del negocio y trans-
acciones del negocio y sus variaciones horarias, semanales y estacionales; los
períodos críticos para cada proceso de negocio; etc.
• Datos de los servicios. Contiene información sobre la capacidad y rendi-
miento de cada uno de los servicios o, por lo menos, de los principales, con
Estructura de la CDB
Datos de Datos utilización

Datos del negocio
los servicios recursos
Límites técnicos
• Procesos de negocio. Por cada servicio: • Comunicaciones
externas. • Límite uso CPU.
• Edificios y • Rendimiento: perfil de
emplazamientos. variación de la carga: • Red interna. • Límite uso
– Picos de carga. almacenamiento.
• Distribución • Cortafuegos.
geográfica usuarios. – Número de • Límite uso red.
transacciones. • Servidores frontales.
• Distribución funcional – Tiempos de • Servidores
usuarios. respuesta. middleware.
• Volúmenes de • Capacidad: consumo • Servidores backend. Información
actividad del negocio. por usuario o • Almacenamiento financiera
• Transacciones de transacción. compartido.
negocio. • Costes del servicio. • TCO por puesto.
• Copias de seguridad
• Perfil de la actividad • Datos de rendimiento • Coste licencias por
del negocio (horario, • Áreas de soporte:
de la infraestructura usuario.
semanal y estacional). – Service desk.
que soporta el servicio.
– Operación. • Coste transacción.
• Períodos críticos para • Concurrencia con otros
– Soporte técnico. • Coste por MIP.
cada proceso de servicios sobre las
negocio. plataformas comunes. • Coste por GB.
TCO: Coste total de propiedad.

MIP: Millones de instrucciones por segundo.
Figura 6.5.8. Estructuración ejemplo de la base de datos de capacidad
detalles horarios. Típicamente se recoge la información sobre el rendimiento

(picos de carga, volumen de transacciones, tiempos de respuesta, perfil de
variación horaria de la carga del servicio, concurrencia en número de usua-
rios, etc.); el rendimiento de los componentes de la infraestructura que
soporta el servicio; la coincidencia de la carga entre los servicios sobre las
plataformas comunes (comunicaciones exteriores, red interna, frontales web,
backend de procesamiento, red almacenamiento, backup, etc.); los niveles de
servicio acordados en los SLA; etc.
Los datos de los servicios se obtienen de las herramientas de monitoriza-
ción extremo a extremo de los servicios y de las herramientas de monitori-
zación específicas de los recursos. Junto a la información técnica se registra
la información necesaria para el cálculo de los costes y su posterior imputa-
ción por el proceso de gestión financiera.
• Datos de utilización de los recursos. Información resultante de la monito-

rización de los recursos. Cada recurso tiene sus propios parámetros de moni-
torización y, para cada uno de ellos, se mide la utilización de los componentes
y el rendimiento. Así, se monitorizarán las aplicaciones; las comunicaciones
exteriores; las comunicaciones entre los edificios; las comunicaciones internas
en los centros de datos; los principales equipos de comunicaciones; el equipa-
miento de seguridad; los servidores frontales web, middleware y backend; el
almacenamiento compartido en red LAN o en red SAN; las copias de seguri-
dad o backup; la carga de trabajo de las unidades de soporte (service desk, ope-
ración, soporte técnico, pruebas); etc.
Los parámetros típicos de monitorización son el número de transacciones, el
tiempo de respuesta de las aplicaciones, el tiempo de respuesta de red, el por-
centaje de utilización del procesador, el porcentaje de utilización de disco
compartido, utilización de memoria en los servidores, duración del proce-
sado por lotes (batch), etc.
• Límites técnicos de los recursos. Cada recurso tiene un límite de capacidad
por encima del cual se satura y se degrada su comportamiento. Es el caso del
porcentaje de utilización del procesador, de la capacidad libre de almacena-
miento o de la saturación de las comunicaciones. Esta información se alma-
cena en la CDB. Con estos valores límite, se definen los umbrales y alarmas
de monitorización.
• Información financiera. Conjunto de datos económicos que se necesitan
en el proceso para establecer el punto de equilibrio entre la técnica y el coste,
como se realiza en la definición de escenarios. La información sobre el
entorno económico en el que moverse y los costes se obtienen de varias
fuentes: los planes financieros del negocio, los presupuestos de TI, los sumi-
nistradores, la base de datos de gestión de la configuración (CMDB), etc.
Con la información de la CDB también se obtienen informes, por ejemplo, de los

servicios y recursos; de las excepciones; de las previsiones de capacidad; o del con-
sumo y la facturación.
Debido a la dificultad de integrar los datos provenientes de las diversas herramien-
tas de monitorización, normalmente la base de datos de la capacidad estará for-
mada por varios repositorios de información. Resulta esencial el control de la cohe-
rencia de la información y de la fiabilidad de los datos, por lo que se debe designar
quién o quiénes desempeñarán el rol de administradores y quiénes accederán en
modo de sólo consulta. Como toda base de datos, deberá ajustarse a las políticas
de gestión del cambio. También deberían realizarse controles o revisiones internas
periódicas de los contenidos de la CDB.
Hay que determinar claramente la frontera entre la base de datos de la capacidad,

la base de datos de gestión de la configuración (CMDB) y la información finan-
ciera, con el fin de evitar el tratamiento duplicado de información.
Gestión de la capacidad del negocio

Como se indica en ITIL, “el objetivo principal del subproceso de gestión de la
capacidad del negocio es asegurar que se tienen en cuenta y se comprenden los
requisitos futuros del negocio respecto a los servicios de TI, y que se planifica e
implementa la capacidad suficiente para dar soporte a los servicios, en los plazos
adecuados”.
También en ISO/IEC 20000-2 se establece la necesidad de alinear la gestión de la
capacidad con los requerimientos y previsiones de carga del negocio.
UNE-ISO/IEC 20000-2
Los requisitos actuales y esperados del ciones en la carga de trabajo o en el

negocio en relación al servicio se debe- entorno deberían ser predecible; se
rían conocer en términos de lo que el deberían recoger y analizar datos actua-
negocio va a necesitar para dar servicio les e históricos de utilización de compo-
a sus clientes. nentes y recursos, al nivel adecuado,
con el fin de dar soporte al proceso.
Las previsiones de negocio y las estima-
ciones de carga de trabajo se deberían La gestión de la capacidad debería ser
traducir a requisitos específicos y quedar el punto focal de todas las cuestiones
documentadas. El resultado de las varia- de rendimiento y capacidad.
Del conjunto común de actividades del proceso, las principales actividades que se
pueden considerar para llevar a cabo el subproceso de gestión de la capacidad del
negocio son las siguientes:
Elaborar el plan de capacidad en el ámbito del negocio. Se centra en identificar
la evolución y las necesidades que tendrá el negocio en el período cubierto por el
plan. Las necesidades se convertirán en los requisitos que TI debe satisfacer. En esta
actividad se desarrolla el apartado del plan de capacidad relativo a los “escenarios del
negocio”, que está formado por dos subapartados: la situación actual del negocio y
la evolución prevista del negocio. El objetivo principal es predecir la evolución del
negocio en los aspectos que puedan impactar en TI, como por ejemplo, el volumen
de actividad, la variación o la diversificación de actividades, la incorporación de nue-
vas tecnologías, el impulso a la movilidad, las políticas de teletrabajo, etc.
Idealmente, el plan de capacidad en el ámbito del negocio no se realiza aislada-

mente, sino que forma parte de un ejercicio de estrategia más amplio y global de la
empresa. Parte con la definición de la estrategia del negocio, de los planes de nego-
cio, del avance de la tecnología y de la estrategia de TI alineada con el negocio. La
estrategia de TI se ejecuta en base a un porfolio de proyectos (para la evolución de
los servicios ya existentes o para la construcción de los nuevos), que produce como
resultado el nuevo catálogo de servicios. El plan de capacidad, cuando se realiza en
este ámbito ideal, obtiene la información de los planes del negocio y la estrategia
de TI para predecir la carga de trabajo que recaerá en TI.
El análisis se realiza por áreas o procesos de negocio, mostrando la situación histó-
rica, la actual y las predicciones. Las predicciones utilizan la información de los
“datos de negocio” de la CDB, por lo que la estructura de las predicciones y de la
CDB deberán estar armonizadas.
En la figura 6.5.9 se muestra un ejemplo de los resultados del apartado 3 del plan
de capacidad, relativo a la identificación de los escenarios del negocio. Se ha
tomado como ejemplo una empresa con una estrategia expansiva territorialmente,
con foco en nuevos productos de mayor valor añadido, la diversificación de los
canales de venta, la ampliación de los horarios comerciales y una fuerte expansión
territorial en China y Latinoamérica. En el ejemplo, el escenario del negocio está
alineado con la estructura de datos recopilados en la CDB.
Conviene tener presente que el contacto con el negocio lo lidera el proceso de relacio-
nes con el negocio, al que el presente proceso le asiste en el aspecto de la capacidad.
Si no existiera un ejercicio formalizado de estrategia del negocio y de TI, la defini-
ción del plan de capacidad se deberá realizar, igualmente, utilizando el ejercicio pre-
supuestario como palanca.
Ciclo de mejora de la capacidad y rendimiento del negocio. Esta rutina en con-

tinua ejecución en el proceso, propone mejoras de capacidad o rendimiento moni-
torizando la actividad del negocio a través de su utilización de los servicios (altas
de clientes, transacciones de venta, etc.).
Relacionarse con otros procesos. El subproceso de gestión de la capacidad del
negocio actúa a modo de interfaz entre la gestión de la capacidad y el resto de pro-
cesos de TI.
• Ayuda en la definición de los requerimientos del servicio (SLR) en temas
relativos a la capacidad y rendimiento, asistiendo al proceso de gestión de
nivel de servicio.
• Participa en el diseño, provisión y modificación de los servicios en temas
relacionados con la capacidad, rendimiento, adquisiciones, tecnología, etc.
Plan de capacidad: escenarios del negocio
Escenario Situación actual del negocio Evolución prevista

del negocio Año -2 Año -1 Año 0 Año +1 Año +2 Año +3
• Estrategia negocio. Expansión europea, crecimiento ventas • Expansión intercontinental.

• Venta web y logística: 24x7.
• Nuevos productos con mayor valor añadido.
• Un 50% del personal con movilidad.
• Un 30% del personal en teletrabajo.
• Procesos de negocio:
+10% +10% +10% +15% +15% +25%
– Ventas.
+10% +10% +10% +10% +5% +5%
– Fabricación.
• Edificios y emplazamientos. Consolidación nacional y presencia UE Expansión LATAM y China
• Distribución geográfica <tabla de usuarios por ciudades> <nueva tabla de usuarios por ciudades>
usuarios.
• Distribución funcional <tabla de usuarios por departamentos> <tabla de usuarios por departamentos>
usuarios.
• Transacciones de negocio. <tabla histórico transacciones> <tabla estimación transacciones>
• Perfil de la actividad Horario de L a V de 9 a 20 h Horario comercial: L a D de 9 a 22 h

del negocio (horario, Horario web: 24x7 incluido CRM
semanal y estacional).
• Periodos críticos para cada • Ventas: diciembre. • Ventas: diciembre, julio y septiembre.
proceso de negocio. • Facturación: última semana mes. • Facturación: continua.
• Cierre contable: última semana mes. • Cierre contable: última semana mes.
Figura 6.5.9. Ejemplo del apartado de escenarios del negocio

en un plan de capacidad
• Verifica los acuerdos de nivel de servicio (SLA), asesorando al gestor de nivel

de servicio y responsabilizándose de los temas de rendimiento en los servi-
cios comprometidos.
• Apoya en la negociación de los SLA, realizando, si es necesario, técnicas pre-
dictivas del rendimiento.
• Controla cambios y entregas, especificando las pruebas de rendimiento que
se deben realizar y comprobando que se realizan.
Modelado de la actividad del negocio. El modelado, en cualquiera de sus formas

simples o complejas, permitirá tener una predicción de la evolución de la actividad
del negocio. El modelado también relaciona diversos procesos de negocio con el

fin de identificar la concurrencia de los picos de demanda. Servirá como entrada
para el modelado de los servicios y las previsiones del plan de capacidad. El mode-
lado presenta como resultado una tabla o gráfica con la evolución de la actividad
del negocio en parámetros trasladables a la carga sobre TI.
Realización de informes de capacidad y rendimiento del negocio. Se realizan
informes sobre la evolución del negocio y su reflejo en los principales parámetros
de la actividad del negocio con impacto en TI.
Gestión de la capacidad de los servicios

El subproceso de gestión de la capacidad de los servicios se centra en que los servi-
cios tengan los recursos necesarios para que estén operativos. Teniendo como obje-
tivo el cumplimiento de los requisitos de los servicios (SLR) y los acuerdos de nivel
de servicio (SLA), analiza su utilización, su rendimiento, el consumo de recursos,
los patrones de trabajo, las subidas y bajadas de carga.
En ISO/IEC 20000-1 se exige expresamente que se monitorice la capacidad y ren-
dimiento de los servicios.
UNE-ISO/IEC 20000-1
Se deben identificar métodos, procedimientos y técnicas para la monitorización de

la capacidad del servicio, el ajuste del comportamiento y de las prestaciones del ser-
vicio y la provisión de la adecuada capacidad.
ISO/IEC 20000-2 recomienda la realización del dimensionamiento y modelización

de los servicios.
UNE-ISO/IEC 20000-2
El proceso debería ofrecer soporte directo dimensionamiento y una modelización de

al desarrollo de servicios nuevos y a la servicios.
modificación de los mismos realizando un
Elaborar el plan de capacidad de los servicios. En esta actividad, el subproceso

elabora el apartado 7, dedicado al resumen de los servicios del plan de capacidad.
Realiza un mapa de la situación actual de los servicios y sus datos históricos, y el

pronóstico de la evolución de la carga de los servicios.
El plan de capacidad de los servicios hace una previsión de la carga que llegará a los
servicios y las necesidades de infraestructura para soportarla. Las previsiones de
carga de los servicios y la concurrencia de las mismas cobran especial relevancia en
escenarios con servidores consolidados y virtualizados.
Hay que tener en cuenta las situaciones transitorias en las que la carga aumenta,
como por ejemplo, la ejecución en paralelo de dos servicios que se realizan en la
puesta en marcha de nuevos servicios utilizando elementos comunes, que requieren
que el antiguo y el nuevo estén operativos.
Ciclo de mejora de la capacidad y rendimiento de los servicios. Este conjunto
de 4 actividades tiene su máximo interés en la mejora de los servicios puestos en
producción. Este ciclo debe actuar de forma continua.
• Monitorización. Seguimiento automatizado mediante herramientas de la
capacidad y el rendimiento de los servicios. La monitorización de los servi-
cios se realiza, principalmente, mediante dos técnicas complementarias:
– Monitorización de extremo a extremo mediante puestos de navegación,
unos puestos situados en la red de usuarios lanzan rítmicamente unas
transacciones o navegación predeterminadas.
– Visión del servicio (service view). La monitorización extremo a extremo se
suele complementar con una visión del estado de los servicios obtenida en
base a la monitorización uno a uno de todos los componentes que utiliza
el servicio, teniendo en cuenta las redundancias de los mismos.
• Análisis. Estudio de los resultados de la monitorización para detectar mejoras.
• Ajuste o tunning. Cobra especial importancia en los servicios en fase de
pruebas o recién implantados en producción. Muchas veces las mejoras
obtenidas por el ajuste son de tal calibre que sin él los servicios no serían
utilizables.
• Implementación. Implantación de las mejoras identificadas (análisis o
ajuste), siempre bajo el proceso de gestión del cambio, generando las peti-
ciones de cambio (RFC) correspondientes.
Influir en la utilización de los servicios. El objetivo principal es evitar los malos

usos o utilización desmedida de los servicios. Dados los recursos limitados de TI, es
necesario establecer los mecanismos para que los usuarios sean conscientes de que la
utilización no necesaria de servicios de TI puede tener un impacto negativo en el
negocio debido a la utilización de recursos limitados. La influencia en la utilización
debe ejecutar las políticas de TI y utiliza como principal medio la imputación de cos-
tes, pero también tiene otras alternativas, como por ejemplo, la comunicación, la
limitación del uso (por ejemplo, el tamaño de los buzones de correo), etc. La
influencia en el uso se debe realizar con una visión general del negocio, pues muchas
veces infringe graves prejuicios e improductividad en el negocio. Además, se deben
realizar de forma alineada con la gestión de la estrategia del negocio y apoyadas en
la gestión financiera de TI.
Modelado de los servicios. En el caso de los servicios, el modelado permite definir
varios escenarios de trabajo, con variaciones en la carga que soportarán los servicios
y la cuantificación de los recursos necesarios para soportarla. El modelado se utiliza
en la etapa de diseño de los servicios. En la mayoría de los casos el resultado es una
simple tabla o gráfica que representa las diversas cargas junto con los recursos nece-
sarios. En el caso de productos software, el modelado debe partir del realizado por
los propios fabricantes, que se podrá complementar con pruebas en el escenario real,
ya que los datos de los fabricantes generalmente se referirán a configuraciones “lim-
pias” y que no consideran escenarios de compartición de los recursos.
Dimensionado de aplicaciones. Actividad muy similar al modelado cuyo resul-
tado está orientado a conocer con detalle los recursos que necesitará una aplicación
para satisfacer los niveles de servicio. Se realiza o al inicio del proyecto o en la fase
de pruebas y también se puede hacer en cambios importantes. Si se ha realizado el
modelado previamente, se utilizarán sus resultados. Se realiza principalmente en
aplicaciones críticas. En los desarrollos a medida, sólo se podrá realizar en la fase
de las pruebas finales antes de entrada en producción, sometiendo a la aplicación a
diversas situaciones de carga, utilizando para ello herramientas de generación auto-
mática. Por este motivo, es mucho más importante la identificación e incorpora-
ción de requisitos de rendimiento durante la fase de establecimiento de requisitos
técnicos al nuevo desarrollo.
Realización de informes de capacidad y rendimiento. Emisión de informes
sobre los servicios, detallando el rendimiento de los servicios, la utilización de
recursos (técnicos y humanos), la capacidad remanente, etc. Los informes se reali-
zarán de forma periódica o bajo petición, en ambos casos coordinados con el pro-
ceso de gestión de informes.
Gestión de la capacidad de los recursos

Después de una visión de los servicios y del “racimo” de recursos que cada uno aglu-
tina, es necesario un tratamiento de la capacidad de los recursos por especialidades:
comunicaciones, servidores, almacenamiento, etc. Esta visión, centrada en un tipo de
recurso, permite tener a punto todos los engranajes que forman un servicio. Tratar
los recursos por especialidades permite que un conjunto de especialistas gestione un

pool grande de recursos similares.
El subproceso de gestión de la capacidad de los recursos se centra en la capacidad
y rendimiento de estos elementos de la infraestructura. Procura un uso óptimo de
los recursos hardware y software (si bien en ITIL v2 las personas no son considera-
das como recursos salvo que sean “sustitutivos” de un componente, en ITIL v3 sí
son considerados como recursos, ya que, al fin y al cabo, representan un aspecto
de capacidad fundamental en la prestación de numerosos, si no todos, los servi-
cios de TI).
Elaborar el plan de capacidad de los recursos. El subproceso participa en la ela-
boración del apartado 8 “Resumen de los recursos” del plan de capacidad. El obje-
tivo es detallar los recursos actuales y estimar las necesidades para los próximos
períodos. Con estos pronósticos se elaboran las necesidades presupuestarias que
proporcionarán una parte de los fondos que necesita TI.
Ciclo de mejora de la capacidad y rendimiento. El análisis de los elementos per-
mite detectar oportunidades de mejora técnica en la configuración de cada ele-
mento. Unos componentes bien ajustados serán capaces de proporcionar un rendi-
miento máximo en los picos de carga. La monitorización de los componentes es
fundamental para esta actividad.
Realización de informes de capacidad y rendimiento. Son informes técnicos,
que analiza un pool de recursos.

Las métricas de este proceso se consideran internas a TI, pues al contrario que en
el caso de la disponibilidad, los clientes no están nada interesados en conocer los
ratios de ocupación, los indicadores de saturación o el grado de precisión de
los planes de capacidad. La medición de la gestión de la capacidad se centra, por
una parte, en el seguimiento del uso de la capacidad en los servicios (ratios de utili-
zación de procesador y de almacenamiento), y por otra, en informar sobre el desem-
peño del propio proceso (desviación en las predicciones).
Las principales métricas del proceso son las siguientes:
• Porcentaje de uso de CPU, que da una idea de las holguras que existen en la
capacidad de proceso. También se suele medir el consumo de memoria.
• Porcentaje de disco asignado sobre el total de la capacidad de almacenamiento
en disco instalada.
• Porcentaje de servidores saturados.

• Porcentaje de elementos de red saturados.
• Porcentaje de presupuesto gastado en compras urgentes sobre el presupuesto
total, que indica el grado de precipitación debido a nuevos temas no previs-
tos, precipitación en las ampliaciones, etc.
• Porcentaje de incidencias provocadas por falta de capacidad o de rendi-
miento, que muestra claramente si el proceso es eficaz o no. De forma simi-
lar, se puede medir el porcentaje de no disponibilidad o los incumplimientos
de SLA provocados por la falta de capacidad.
• Porcentaje de desviación previsto en el plan de capacidad frente al real utili-
zado, que indica la precisión de las estimaciones realizadas.
• Desviaciones del plan medidas en términos presupuestarios.
• Porcentaje de servicios o de componentes hardware monitorizados.
• De cara a medir la actividad del proceso se pueden medir el número de reco-
mendaciones hechas por la gestión de la capacidad o el número de cambios
propuestos por la gestión de la capacidad y que han dado lugar a cambios.
• El coste que supone tener sobrecapacidad instalada (y no utilizada), especial-
mente útil en organización en outsourcing o en licenciamiento de sofware que
se pague en base a la capacidad instalada.
• La capacidad de trabajo de la organización, que se puede medir como la
capacidad de cumplimiento de los plazos comprometidos en incidencias,
peticiones, cambios y trabajos planificados (jobs).
• Porcentaje de procesos de negocio modelizados por la gestión de la capa-
cidad.
En la figura 6.5.10 se muestran los indicadores más relevantes para este proceso
recomendadas por itSMF España.
Roles participantes en la gestión de la capacidad

La gestión de la capacidad tiene una parte inicial de actividad orientada a la implan-
tación del proceso, a la definición de la estructura del plan de capacidad, a la reali-
zación del primer plan, a la definición de la forma de modelizar el negocio, a la
implantación de las herramientas de monitorización (o establecimiento de los
umbrales y alarmas), etc. Esta parte de implantación, no es frecuente realizarla en
de itSMF España
base a un proyecto llave en mano, como puede ocurrir con la continuidad, sino que
se suele realizar por el propio equipo que posteriormente llevará el proceso.
Una vez puesta en marcha, la gestión de la capacidad requiere perfiles con una pro-
funda especialización técnica en las tecnologías que se utilizan (se realiza en tuning
de aplicaciones, se resuelven problemas de rendimiento, etc.) y también es necesario
conocimiento del negocio de cara a predecir el comportamiento del mismo.
Los roles involucrados en la gestión de la capacidad se estructuran en roles propios
del proceso y roles ajenos al proceso.
• Gestor de la capacidad. Es el responsable de la implantación del proceso defi-
nido por el propietario del modelo de gestión. También supervisa y coordina
la ejecución y el control del proceso, se encarga de proponer mejoras al pro-
ceso, realiza el plan de capacidad, tiene la visión del negocio, interactúa con
el resto de procesos, asegura que se cumplen los SLA en cuanto a la capaci-
dad y rendimiento, vela por el correcto tratamiento de los datos que utiliza
el proceso y supervisa la implementación de la monitorización.
• Administrador y soporte del proceso de capacidad. Asiste al gestor de la
capacidad en lo que necesite.
• Especialistas en monitorización. Implementan y gestionan la plataforma de

monitorización. Con frecuencia este rol está desempeñado por un grupo téc-
nico especializado que gestiona toda la monitorización.
• Especialistas tecnológicos. Bajo este rol se incluye todo el personal técnico
necesario para gestionar las distintas tecnologías, como por ejemplo las
redes, los sistemas, las bases de datos, el middleware, las aplicaciones, la segu-
ridad, el backup, el procesado batch, etc.
• Administrador de la base de datos de capacidad (CDB). Técnico responsable
de mantener las herramientas en las que se almacenan los datos e informa-
ción de la capacidad.

• El gestor de las relaciones con el negocio, pues actuará de interlocutor de
cara a las previsiones del negocio, la toma de requisitos y el acuerdo de los
SLA. También participa en la revisión de informes de seguimiento con el
negocio.
• El gestor de nivel del servicio, transmite los requisitos de los servicios y los
SLA en relación a capacidad y rendimiento.
• El gestor de disponibilidad, por la fuerte relación técnica entre disponibili-
dad, tiempo de respuesta, capacidad y rendimiento.
• El gestor del incidente y el gestor del problema, pues proporcionan informa-
ción de las incidencias cuyo origen está en la capacidad o rendimiento.
• El gestor del cambio o gestor de la entrega, por la necesidad de que controle
la realización de las pruebas sobre el consumo de capacidad y realice el tuning
de las aplicaciones antes de su paso a producción.
• El gestor financiero de TI aporta los costes unitarios y recibe las estimacio-
nes presupuestarias del plan de capacidad, dado que el plan de capacidad está
muy relacionado con los presupuestos.
• El propietario del modelo de gestión SGSTI, que actúa como propietario del
proceso (process owner), define las actividades del proceso y se encarga de la
mejora continua del mismo.
Los roles de mayor relevancia que participan en el proceso de gestión de la capaci-

dad de representan la figura 6.5.11.
Roles del proceso
Responsable de la
Administrador y
Gestor de soporte del proceso
la capacidad de capacidad
Gestores de otros procesos:

relaciones, financiero y entrega
SGSTI
Especialista
tecnológico
Especialista en Administrador
monitorización de la CDB
Propietario del
modelo (SGSTI)
Figura 6.5.11. Roles del proceso de gestión de la capacidad
Resumen
Si este proceso cayó alguna vez en el olvido, vuelve a tener plena vigencia debido a
las nuevas tendencias en TI: los ajustes en los costes, la consolidación y la virtuali-
zación de las infraestructuras de procesamiento o la reducción del consumo eléc-
trico. La necesidad de compartir plataformas requiere gestionar y controlar los
recursos que consume un servicio para evitar que interfiera en el rendimiento de
los otros.
La gestión de la capacidad es un proceso que comprende un amplio abanico de
especialidades diferentes, desde el entendimiento de la evolución del negocio, hasta
las funciones más técnicas de ajuste de las aplicaciones y de las plataformas para
conseguir un rendimiento óptimo.
El proceso se revitaliza con la realización del plan de capacidad y sus revisiones

periódicas, lo que le obliga a estar al tanto de las tendencias del negocio y sus varia-
ciones en la utilización de los servicios, estar al día de la evolución tecnológica y de
la situación económica de la empresa.
La gestión de la capacidad se estructura en tres subprocesos o áreas de actividad:
• La gestión de la capacidad del negocio: que traslada las necesidades y planes
del negocio en requisitos para los servicios y las infraestructuras, con el fin
de asegurar que los futuros requerimientos del negocio se puedan cumplir.
• La gestión de la capacidad de los servicios: está centrado en la gestión, control y
predicción del rendimiento extremo a extremo de los servicios para el cumpli-
miento de los requisitos del servicio y los acuerdos pactados de nivel de servicio.
• La gestión de la capacidad de los recursos: cuyo objetivo es la gestión y el
control de los recursos de TI, y especialmente de los más esenciales para que
presten el mejor rendimiento posible.
En estas tres áreas se realizan el siguiente conjunto de actividades.

• La elaboración del plan de capacidad, que sincroniza a toda la organización
en las previsiones de recursos necesarios para satisfacer la evolución de las
demandas del negocio.
• El ciclo de mejora de la capacidad y rendimiento garantiza que se están revi-
sando estos parámetros de forma continua. Se inicia en la monitorización,
sigue con el análisis de los datos, para identificar las necesidades de ajuste o
tuning de aplicaciones y de infraestructuras, para realizar posteriormente la
implementación de las mejoras a través del proceso de cambios.
• Influir en la utilización de los servicios y consumo de recursos es otra de las
facetas que desarrolla el proceso. Despliega las condiciones (comunicación,
facturación, etc.) para que el uso transcurra por la senda prevista.
• Se realiza el modelado de los servicios, con el fin de tener una previsión de
su comportamiento en situaciones de carga pico.
• El dimensionado de aplicaciones en las fases tempranas de su concepción,
permitirá anticipar las necesidades de infraestructuras.
• Realiza los informes de capacidad y rendimiento de los servicios y los recursos.
• Crea y administra la base de datos de capacidad (CDB), que centraliza la
información de monitorización de la capacidad y del rendimiento.
• Como en el resto de los procesos, se supervisa a sí mismo y se mejora.
El proceso de gestión de la capacidad es el proceso “tacaño” por excelencia, velando

por la optimización y evitando derroches. Por ello, año tras año, se irá viendo cómo
la gestión de la capacidad va cobrando mayor relevancia en un mundo que requiere
ajustar al máximo el consumo de recursos materiales y energéticos.
Beneficios
La gestión de la capacidad es un proceso de previsión que permite anticipar las
necesidades y gestionar la dotación de fondos para conseguirlos. Por tanto, tiene
una vertiente importante en la planificación económica.
También lucha contra el despilfarro en la compra o utilización de los recursos, ajus-
tando la demanda a las infraestructuras necesarias.
En su faceta técnica pura, se centra en conseguir un rendimiento óptimo de los ser-
vicios, realizando el ajuste fino de las aplicaciones y de las plataformas.
Los principales beneficios esperados con la implantación de este proceso son los
siguientes:
• Se conocen anticipadamente las necesidades de recursos.
• Se pueden agrupar y racionalizar las compras.
• El diálogo con el negocio permite identificar los perfiles de utilización de los
servicios y reconducir el consumo que se hace de ellos por parte de los usua-
rios.
• Se controlan los gastos imprevistos por nuevos proyecto o por necesidades
de compras urgentes.
• La optimización de recursos, la revisión de la utilización de licencias, la ges-
tión de la obsolescencia del parque de equipamiento y la retirada de recursos
no utilizados, pueden generar importantes ahorros.
• La mejora del rendimiento y el tunning es una garantía para la estabilidad de
los servicios y la utilización óptima de los recursos.
• La monitorización permitirá seguir el consumo de capacidad (por ejemplo,
el consumo energético) y el rendimiento.
• El ciclo de mejora de la capacidad asegura que las instalaciones están siendo
revisadas y mejoradas continuamente.
Por tanto, el proceso de gestión de la capacidad aporta predicción en las necesida-

des, con los beneficios que trae consigo la anticipación. Es un proceso de ajuste y
corrección de los excesos, tanto en el uso como en la dotación de equipamiento.

Además, es un proceso técnico en el que se afina el funcionamiento de la maquina-
ria de TI. Aportará un mejor control de los costes en las plataformas y una mayor
estabilidad en las mismas.
• ¿Cuál es el contenido del plan de capacidad de su organización?
• ¿Cómo se realizan las pruebas de rendimiento de las aplicaciones?
• Cite las dos mejores prácticas de su organización relativas al proceso
de capacidad.
1
6.6. Gestión de la seguridad de la información 403
6.6. Gestión de la seguridad de la información
Figura 6.6.1. Actividades del proceso de gestión de la seguridad de la información
En los últimos años la seguridad de las tecnologías de la información se ha conver-

tido en una de las preocupaciones más importantes de las empresas. La información
es quizá uno de los activos más críticos, sin información o con una información alte-
rada, las compañías no pueden desarrollar su actividad. Pero aún conservando la
información, si ésta es accedida y cae en manos de la competencia, o es divulgada en
el mercado, el daño puede ser aún mayor.
La facilidad de acceso a cualquier parte del mundo mediante la gran red Internet,
pone al alcance de la mano cualquier ordenador que esté conectado a ella. Los ata-
ques, los virus, los gusanos y los troyanos son cada vez más frecuentes. La adecuada
gestión de la seguridad de la información se ha convertido por obligación en uno
de los objetivos estratégicos de toda compañía.
Tradicionalmente, la gestión de la seguridad ha sido una actividad aislada del día a
día en TI. Sólo se le daba importancia en situaciones de crisis, era considerada
inconscientemente como una rémora. Con la llegada de las Normas ISO/IEC
20000, la gestión de la seguridad asciende de categoría y se trata de igual a igual
con los procesos más importantes en la gestión de TI. Sale del rincón en el que
estaba postergada para ser considerada parte de los procesos de provisión, que son
proactivos y alinean los servicios con los requisitos del negocio. De hecho, implan-
tar la gestión de la seguridad y sus actividades tiene bastante similitud con la
importante gestión de la disponibilidad. Ambas tienen una fase previa de implanta-
ción, se articulan en torno a un plan, participan en el diseño de los servicios, tienen
actividades proactivas, analizan los riesgos, dan su apoyo en la resolución de los
incidentes y problemas que impactan en la disponibilidad o en la seguridad, tienen
facetas reactivas, generan informes, proponen mejoras, supervisan el funciona-
miento en su ámbito, etc. Teniendo en mente estas similitudes, es más sencillo
entender las grandes directrices de la gestión de la seguridad (véase la figura 6.6.1).
La seguridad en TI ha ido evolucionando desde la resolución de crisis, a golpe de
inversión en tecnología de protección, hacia el concepto de gestión, que combina
tecnología con medidas organizativas, con procesos y con procedimientos de segu-
ridad. La evolución hacia un modelo de gestión de la seguridad de la información
viene impulsada por la Norma UNE-ISO/IEC 27001, que resalta la necesidad de
disponer de un sistema de gestión de la seguridad y la Norma UNE-ISO/IEC
17799 que detalla cada uno de los controles necesarios para garantizar la seguri-
dad.
La empresa actual debe entender la gestión de la seguridad como un proceso, que
garantice y salvaguarde su información, pero que no suponga una barrera para la
organización a la hora de desarrollar su actividad.
La gestión de seguridad de la información es el proceso con responsabilidad sobre
los niveles de seguridad de los activos utilizados para la prestación de los servicios
de TI a los clientes. En la figura 6.6.2 se presenta una introducción al proceso de
gestión de seguridad de la información.
Las Normas ISO/IEC 20000 establecen para este proceso un objetivo muy claro:
“gestionar la seguridad de la información de manera eficaz para todas las activida-
des del servicio”. El proceso de gestión de seguridad de la información debe traba-
jar para asegurar que los activos utilizados en la prestación de los servicios se
encuentren en unos niveles de exposición al riesgo aceptables para el negocio.
Por otra parte, en ITIL v3 se enuncia el objetivo con un enfoque algo diferente: “ali-
near la seguridad de TI con la seguridad del negocio y garantizar que la seguridad
de la información es gestionada de forma efectiva en todas las actividades de la ges-
tión del servicio”. Es muy interesante el matiz añadido por la versión 3, poniendo
énfasis en que la seguridad en TI esté integrada con la seguridad general de la
empresa. También destaca que la seguridad no es una isla dentro del área de TI, sino
que enfoca la actividad del proceso principalmente a velar porque los diversos gru-
pos especialistas de TI desarrollen entre sus actividades los aspectos de la seguridad.
Así, este proceso, al igual que ocurriera con la gestión de la disponibilidad, marca las

seguridad de la información • Reduce el riesgo de virus, troyanos,
gusanos, etc.
• Mejor custodia de los activos de
Definición:
información de la empresa.
Proceso responsable de gestionar la • Aumenta la fiabilidad de los servicios,
seguridad de la información equilibrando reduciendo la probabilidad de
las medidas con los costes que supone incidentes de seguridad.
implementarlas.
• Desarrolla métodos más eficientes
en la resolución de incidentes de
seguridad.
Objetivo:
• Una gestión integral que proporcione
Proceso que debe garantizar el nivel de una visión conjunta del impacto de la
seguridad requerido sobre los activos seguridad en el negocio.
utilizados por la organización para la • Mejora continua del nivel de riesgo
prestación de los servicios de TI. de los servicios prestados a clientes.
Figura 6.6.2. Introducción al proceso de gestión de seguridad de la información
pautas, define las medidas de salvaguardia y vela por que se cumplan, más que des-
arrollar las medidas por si mismo.
Las principales ventajas que aporta el proceso son:
• Mejora la seguridad de los sistemas de información en todos sus aspectos.
Reduce el riesgo de contagio de virus, de entrada de los silenciosos troyanos,
de expansión de gusanos que saturan las comunicaciones, etc.
• Mejora el control y la custodia de los activos de información de la empresa,
implantando medidas adecuadas a la criticidad de la información o de los sis-
temas.
• La mayor protección ante las amenazas permite aumentar la fiabilidad de los
servicios, reduciendo la probabilidad de ocurrencia de incidentes de seguridad.
• Define y prepara métodos eficientes en la resolución de incidentes de segu-
ridad.
• Implementa una gestión integral de la seguridad, que proporciona una
visión conjunta del impacto de la seguridad en el negocio.
• Realiza la mejora continua de la seguridad reduciendo nivel de riesgo de los
servicios prestados a los clientes.
De forma general, la seguridad informática se plantea desde dos ámbitos o discipli-

nas: la seguridad física y la seguridad lógica.
• La seguridad física se centra en la interposición de controles y barreras mecá-
nicas o materiales para el acceso, y en la detección de intrusiones a recintos,
infraestructuras o localizaciones. Entre las medidas habituales de seguridad
física se encuentran los perímetros de seguridad física para proteger las áreas
en las que ubican los sistemas de información; los controles físicos de
entrada-salida; y las medidas de protección frente a incendios, inundaciones,
terremotos, explosiones, disturbios, manifestaciones, atentados o cualquier
otra forma de desastre natural o provocado. La seguridad física se puede
solapar en algunos riesgos con la gestión de la continuidad, por lo que es
conveniente delimitar claramente las fronteras entre ambas.
• La seguridad lógica se centra en la protección de la información en su pro-
pio medio. Algunos ejemplos de medidas de seguridad lógica son el control
del acceso de los usuarios a los sistemas de información; los mecanismos de
control del acceso a la información y a los sistemas; los cortafuegos y las pro-
tecciones en la conexión a las redes de telecomunicaciones; etc.
Cuando se trata de definir el alcance de la seguridad es ya un clásico considerar que se

deben cubrir tres aspectos: la confidencialidad, la integridad y la disponibilidad de la
información. En la figura 6.6.3 se muestran los principios básicos de este proceso.

de gestión de la seguridad de la información
La confidencialidad asegura que sólo acceden a la información aquellas personas

o sistemas que están autorizados. La confidencialidad permite retener el conoci-
miento y los datos fundamentales para el negocio. Permite asegurar que sólo los
usuarios autorizados tienen acceso cuando lo requieran a la información y a sus
activos asociados. Cuando falta confidencialidad se puede producir la divulgación
de información esencial de la empresa o de las personas.
La disponibilidad de la información vela por que esté siempre disponible en el
momento y lugar necesarios, para ser utilizada por las personas autorizadas. Está
propiedad básica de la seguridad, se provee a través del proceso de gestión de la
disponibilidad.
La integridad permite garantizar la exactitud y completitud de la información, así
como, los métodos de su procesado. Esta característica consigue que el contenido
de la información permanezca inalterado, a menos que sea modificada por personal
autorizado.
Existen otras propiedades asociadas a la seguridad que aportan confianza en la
autenticidad y el no repudio de las transacciones o intercambios de información.
También es importante la auditabilidad, característica que permite verificar las
acciones que se han llevando a cabo, quién las ha realizado y en qué momento de
tiempo se han realizado.
El proceso de gestión de la seguridad de la información también requiere que se
traten los incidentes de seguridad. En este caso, se realizará por el proceso de ges-
tión del incidente, es decir, que todo evento o serie de eventos de seguridad de la
información se deben gestionar siguiendo el mismo proceso que cualquier otro
incidente. En el momento en que existe un incidente abierto, su resolución corre
siempre a cargo del único proceso encargado de resolverlo, la gestión del incidente,
mientras que la gestión de la seguridad habrá preparado los procedimientos de
actuación, dejando que transcurra el flujo del incidente. Igualmente ocurre en la
gestión de la capacidad o de la disponibilidad en sus respectivos tipos de inciden-
tes, lo cual no exime de que exista un grupo de especialistas en seguridad que
actúen como segunda opción, pero trabajando para el proceso de incidentes.
Los conceptos y componentes principales que se utilizan en el proceso son el análi-
sis de riesgos, los activos de información, los riesgos de seguridad, la declaración
de los riesgos, los controles de seguridad o medidas de salvaguardia, el plan de ges-
tión de riesgos, el comité de seguridad y los registros que detallan los eventos e
incidentes de seguridad. En la figura 6.6.4 se muestran los principales elementos
que intervienen el proceso de gestión de seguridad de la información.
Adicionalmente a los principios básicos de la seguridad (confidencialidad, disponi-
bilidad, integridad, autenticidad, no repudio, auditabilidad y gestión de incidentes
Evaluación Declaración Tratamiento Supervisión
Activo Riesgos de
seguridad
Objetivos
de control • Monitorización
de la seguridad
Amenaza
• de seguridad Declaración de Controles de
Eventos de
riesgos (SoA) seguridad • seguridad
• Vulnerabilidad Plan de
• Probabilidad tratamiento de
Incidentes
riesgos de
• Impacto seguridad de seguridad
• Nivel de riesgo
Registros de
seguridad
d
• Informes
seguridad
de
da
eg uri Comité de
es
ad seguridad
ític
Pol
Figura 6.6.4. Componentes del proceso de gestión de seguridad
de seguridad), hay que tener en cuenta los conceptos principales que se utilizan en
el proceso de gestión de seguridad de la información:
Activo de sistemas de información o elemento de configuración. Dato, infor-
mación, programa, equipo, persona o cualquier otro recurso de los sistemas de
información utilizado en la prestación de los servicios. En el ámbito de seguridad
se denomina “activo”, mientras que en el proceso de gestión de la configuración y
en el resto de procesos se utiliza el término “elemento de configuración”. Así,
activo y elemento de configuración son conceptos similares.
Amenaza. Suceso de ocurrencia probable que puede desencadenar un incidente en la
organización, produciendo daños o pérdidas materiales o inmateriales en sus activos.
Análisis de riesgos de seguridad. Actividad que proporciona información relativa
a las amenazas de seguridad que pueden afectar a los servicios, así como, la probabi-
lidad de que ocurran. En TI se suele realizar un análisis de riesgos específico en cada
uno de los tres procesos (incidentes, continuidad y seguridad), pero con objetivos
distintos: para asegurar la disponibilidad de los sistemas (foco en fallos cotidianos),

para garantizar la continuidad (foco en contingencias severas) o la seguridad (foco
en la malicia humana).
Comité de seguridad. Organismo interno asesor del responsable de seguridad que
centraliza la información y la toma de decisiones en los aspectos de seguridad.
Control de seguridad o medida de salvaguardia. Acción, procedimiento,
medida o dispositivo (físico o lógico) que reduce el riesgo. La gestión de la seguri-
dad se articula en torno a la definición de unos objetivos de control y a la implanta-
ción de los controles necesarios para conseguir los objetivos.
Declaración de riesgos de seguridad. Documento formal que relaciona los ries-
gos con los niveles de exposición a los que está sometida una organización.
Declaración de aplicabilidad (SoA, Statement of Applicability). Declaración de
riesgos específica de ISO/IEC 27001. Documento que detalla los objetivos de con-
trol y los controles de seguridad que se utilizarán (seleccionados de los propuestos
en la Norma ISO/IEC 27001), también se deben justificar cuáles no se consideran
que sean prioritarios o necesarios para el proveedor de servicios de TI. Se basa en
los resultados de la evaluación de riesgos y del tratamiento de riesgos, justificando
las inclusiones y exclusiones. La declaración de aplicabilidad es un requisito formal
de ISO/IEC 27001 y sirve de punto de entrada para planificar el tratamiento de los
riesgos.
Evento de seguridad de la información. Suceso identificado en un activo o ele-
mento de configuración, que indica una posible brecha en la política de seguridad
de la información, fallo de las salvaguardias o una situación que podría ser relevante
para la seguridad.
Impacto. Consecuencia sobre los servicios y el negocio en caso de materializarse
una amenaza.
Incidente de seguridad de la información. Evento o serie de eventos de seguri-
dad de la información que impacta en los servicios de TI.
Informe de seguridad. Informe centrado específicamente en la seguridad, expli-
cando los hechos acaecidos en el período. También puede haber un informe especí-
fico que detalle lo ocurrido en un incidente severo de seguridad.
Monitorización de la seguridad. Sistemas informáticos que supervisan y miden
los controles de seguridad, y registran los eventos de seguridad.
Nivel de riesgo. Grado de exposición a un riesgo.
Objetivo de control. Situación o aspecto que se quiere alcanzar en el ámbito de la
seguridad. La seguridad se implanta definiendo los objetivos de control necesarios
y, para cada uno de estos, se establecen los controles que harán posible alcanzar
el objetivo fijado. Las Normas ISO/IEC 27001 e ISO/IEC 17799 establecen cerca
de 40 posibles objetivos de control de la seguridad de la información.
Registro de seguridad. Información relativa a un aspecto o un evento de seguri-
dad que se almacena de una forma controlada. Los registros son un instrumento
esencial en las normas para desarrollar el principio de auditabilidad.
Plan de tratamiento de riesgos (RTP, Risk Treatment Plan). Documento base
que articula la implantación de la gestión de los riesgos.
Plan Director de Seguridad de la Información (PDSI). Nombre un poco rimbom-
bante que se suele dar al documento que unifica todas las acciones a varios años para
transformar la seguridad. Tiene categoría de plan estratégico. Normalmente contiene
el plan de implantación del proceso o del SGSI, y el plan de tratamiento de riesgos.
Probabilidad. Frecuencia con la que puede ocurrir un suceso, o la relación entre el
número de casos favorables y el número de casos totales.
Riesgo. Es la posibilidad de que se materialice una amenaza y ésta cause un
impacto en un determinado servicio o activo. El riesgo es función de la magnitud
de la amenaza, de la vulnerabilidad al mismo de los servicios y de la probabilidad
de que ocurra el suceso. En torno al riesgo aparecen un conjunto de actividades:
• Aceptación del riesgo. Decisión de aceptar un riesgo.
• Análisis del riesgo. Sistemática de uso de información para identificar fuen-
tes y estimación del riesgo.
• Valoración del riesgo. Todo el proceso de análisis y evaluación del riesgo.
• Evaluación del riesgo. Proceso de comparar un riesgo estimado con el
riesgo dado por los criterios para determinar la importancia del riesgo.
• Tratamiento o gestión del riesgo. Proceso de selección e implantación de
las medidas para cambiar el riesgo.
Sistema de Gestión de la Seguridad de la Información (SGSI, o en inglés

ISMS, Information Security Management System). Es un sistema de gestión o
modelo formalizado con el que se gestiona la seguridad de la información. La
Norma ISO/IEC 27001 define este sistema de gestión.
Conviene que el SGSI esté integrado en el SGSTI y ambos en el sistema de gestión
de la calidad general de la empresa (basado en ISO 9001).
Sistema de Gestión del Servicio de TI (SGSTI). Es un sistema de gestión o
modelo formalizado con el que se gestionan los servicios de las TI. Las Normas
ISO/IEC 20000 definen este sistema de gestión y se explica en el capítulo 3 de

este libro. Ambos sistemas (SGSTI o SGSI) se pueden implementar de forma
independiente, pero lo recomendable es que se implementen de forma integrada
entre sí, e integrados en el sistema de gestión de la calidad general de la empresa
(ISO 9001).
Vulnerabilidad. Debilidad o escaso blindaje de un activo para resistir a una ame-
naza.

La seguridad es un proceso poco conocido para los iniciados en la gestión de los
servicios. Muchas veces se implementa por grupos de personas diferentes, unos
especializados en ITIL y los otros en seguridad. El proceso parte de unas políticas
dictadas por la dirección, se planifica su implementación, se realiza un análisis de
riesgos y se determinan unas soluciones o medidas de protección a implementar. A
partir de este punto, se realiza la supervisión, se prepara la actuación ante inciden-
tes de seguridad, se registran estos y se presentan informes. Como en el resto de
procesos, debe tener una actividad de mejora de si mismo.
La Norma ISO/IEC 27001 y la Norma ISO/IEC 17799 asociada son la mejor
referencia para cumplir con creces los requisitos de ISO/IEC 20000. Así se reco-
noce de forma expresa en la parte 2 de la norma. Por ello, estas dos normas se utili-
zan en este libro como base para estructurar el proceso.
UNE-ISO/IEC 20000-2
Generalidades
El personal del proveedor del servicio
La seguridad de la información es el con roles de especialista en seguridad
resultado de un sistema de políticas y de la información debería estar familia-
procedimientos diseñados para identifi- rizado con la norma ISO/IEC 17799,
car, controlar y proteger la información y Tecnologías de la información. Técni-
cualquier equipamiento empleado junto cas de seguridad. Código de prácticas
con el almacenamiento, transmisión y para la gestión de la seguridad de la
procesamiento de dicha información. información.
La gestión de la seguridad se centra en proteger los activos de información. En el

núcleo central del proceso se realiza una evaluación de riesgos, para seleccionar las
medidas necesarias de protección (controles) e implementarlas de forma organizada
en un plan de tratamiento de riesgos. Pero hay que entender que la seguridad no se

resuelve sólo a golpe de tecnología. Por ello, los controles son de todo tipo: directri-
ces, organizativos, procedimentales, tecnológicos, culturales, etc. Además, una vez
implantados, hay que supervisar el correcto funcionamiento de los mismos,
entrando en el círculo de mejora continua.
Las interacciones y funcionalidades de la gestión de seguridad de la información se
presentan en la figura 6.6.5.
Desencadenantes 3 Creación del proceso o SGSI: Salidas principales:

del proceso: • Alcance, política y enfoque. Ü Política de
Ü Política de seguridad • Proyecto implantación. seguridad TI.
del negocio. Ü Evaluación de riesgos.
• Evaluación de riesgos.
Ü Requisitos de seguridad Ü Plan de tratamiento de
del negocio. • Selección de objetivos de
control y sus controles. riesgos de seguridad.
Ü Acuerdos seguridad en Ü Declaración de riesgos.
SLA. • Declaración de riesgos.
Ü Objetivos de control.
Ü Incidente severo de 3 Implementación y operación:
seguridad. Ü Controles de seguridad.
• Plan de tratamiento de riesgos.
Ü Fecha de pruebas. Ü Registros de seguridad.
• Implementar controles.
Ü Fecha revisión del plan. Ü Auditorías de
• Procedimiento incidentes
seguridad.
Ü Fecha de auditorías. seguridad.
ÜInformes de seguridad.
• Pruebas iniciales.
• Gestionar recursos Salidas secundarias:
Ü Análisis de riesgos y plan seguridad.
de continuidad de TI. Ü Requisitos de seguridad.
Ü Información de 3 Supervisión y revisión: Ü Plan proyecto seguridad.
incidentes y problemas. • Formación y comunicación. Ü Procedimientos de
Ü Datos de monitorización. • Revisión y auditoría. detección y respuesta a
incidentes de seguridad.
Ü Cambios (RFC). • Pruebas de los controles.
Ü Activos clasificados.
Ü Activos y CMDB. • Supervisar, monitorizar y
registrar. Ü Personal concienciado.
Ü Entorno legal.
• Investigar incidentes. Ü Informes resultados
Ü Presupuestos asignados.
pruebas de seguridad.
• Actualizar los planes.
• Gestionar incidentes severos
de seguridad.
3 Mantenimiento y mejora
Fuente: e.p. a partir de UNE-ISO/IEC 27001-1.
Figura 6.6.5. Entradas, actividades y salidas

de gestión de seguridad de la información
Las entradas desencadenantes del proceso son la definición de una política de segu-
ridad en el negocio, que origina el inicio de la creación del proceso; los requisitos
de seguridad del negocio concretados en los acuerdos de nivel de servicio; la ocu-
rrencia de un incidente severo de seguridad, pues este proceso colabora con la ges-
tión del incidente en la gestión de la crisis; y la llegada de un conjunto de fechas
específicas (de pruebas de seguridad, de revisión del plan de tratamiento de riesgos
o las fechas de las revisiones o auditorías).
El proceso utiliza unas entradas de soporte de otras fuentes necesarias para llevar a
cabo sus cometidos. Entre dichas entradas destacan el análisis de riesgos realizado en
el plan de continuidad de TI, pues en caso de que se haya realizado aportará un enten-
dimiento mejor del negocio y de los riesgos; la información de incidentes y de los pro-
blemas ocurridos relacionados con la seguridad; los datos de la monitorización de los
sistemas y de la seguridad; los cambios en curso para supervisar que se evalúe su segu-
ridad; la información de los activos y de la CMDB; el entorno legal y regulatorio que
influye en la seguridad; los presupuestos asignados a la seguridad; etc.
Las salidas principales del proceso son la política de la seguridad definida; los resul-
tados de la evaluación de riesgos de seguridad; el plan de tratamiento de los riesgos;
la declaración de riesgos; los objetivos de control y los controles seleccionados; los
resultados de las auditorías de seguridad; o los informes relativos a la seguridad y
sus indicadores.
Las salidas secundarias, o de menor importancia, que se obtienen del proceso son,
por ejemplo, los requisitos formalizados para la seguridad; el plan de proyecto para
implantar el proceso de seguridad; los procedimientos para detección y respuesta a
incidentes de seguridad; una clasificación de los activos en cuanto a su criticidad; el
personal de TI y de la empresa concienciado; los informes de los resultados de las
pruebas de seguridad; etc.
En la definición de las actividades del proceso se han tenido en cuenta lo establecido
en la Norma ISO/IEC 27001 en su apartado 4.2, que agrupa las actividades de
gestión de la seguridad en torno al ciclo PDCA de Deming (véase la figura 6.6.6).
Extrayendo cada epígrafe del apartado 4.2 de la Norma ISO/IEC 27001 se esta-
blecen un total de 30 actividades. En la figura 6.6.7 se relacionan éstas.
Como se ha mencionado anteriormente, en este libro se ha decidido respetar lo defi-
nido en ISO/IEC 27001 como la mejor vía para llevar a cabo los requisitos estable-
cidos en las Normas ISO/IEC 20000, además, para facilitar el entendimiento de las
actividades, se ha realizado una agrupación intermedia. De esta forma, en el presente
proceso las actividades de gestión de la seguridad quedan estructuradas en dos nive-
les: el primero alineado el ciclo PDCA de ISO/IEC 27001, mientras que el segundo
nivel permite entender mejor el transcurso del proceso.
P – Planificar A – Actuar
Creación del proceso o SGSI Mantenimiento y mejora
Establecer política, objetivos, evaluar el riesgo, Plan Implementar mejoras, acciones correctivas
seleccionar controles, obtener la aprobación Planificar y preventivas, comunicar resultados,
de la dirección, declaración de riesgos. asegurar implantación de las mejoras.
Do Act
Hacer Actuar
D – Hacer Check C – Verificar
Implementación y operación Verificar Supervisión y revisión
Plan de tratamiento del riesgo, implementar Supervisar, monitorizar, revisiones regulares,
controles, formación, implantar procedimientos medir la efectividad, auditorías, actualizar
gestión incidentes de seguridad. planes, registro de acciones y eventos.
Figura 6.6.6. La gestión de la seguridad se articula en torno al ciclo PDCA
Actividades del sistema de gestión de la seguridad (SGSI) en UNE-ISO/IEC 27001
4.2.1 Creación del SGSI 4.2.3 Supervisión y revisión del SGSI

a) Definir el alcance. a) Ejecutar procedimientos de supervisión y revisión.
b) Definir una política de seguridad. b) Realizar revisiones periódicas de la eficacia del SGSI.
c) Definir el enfoque de la evaluación de riesgos de la c) Medir la eficacia de los controles.
organización. d) Revisar las evaluaciones de riesgos en intervalos
d) Identificar los riesgos. planificados y revisar los riesgos residuales.
e) Analizar y valorar los riesgos. e) Realizar las auditorías internas del SGSI en
f) Identificar y evaluar las opciones para el tratamiento intervalos planificados.
de riesgos. f) Realizar una revisión general del SGSI.
g) Seleccionar los objetivos de control y los controles g) Actualizar los planes de seguridad.
para el tratamiento de los riesgos. h) Registrar las acciones e incidencias que pudieran
h) Obtener la aprobación de los riesgos residuales afectar a la eficacia o al funcionamiento del SGSI.
propuestos.
4.2.4 Mantenimiento y mejora del SGSI
i) Obtener la autorización para implementar y operar
a) Implementar en el SGSI las mejoras identificadas.
el SGSI.
b) Aplicar las medidas correctivas y preventivas
j) Elaborar una declaración de aplicabilidad.
adecuadas.
4.2.2 Implementación y operación del SGSI c) Comunicar las acciones y mejoras a todas las
a) Formular un plan de tratamiento de riesgos. partes.
b) Implementar el plan de tratamiento de riesgos. d) Asegurar que las mejoras alcancen los objetivos
c) Implementar los controles seleccionados. previstos.
d) Definir el modo de medir la eficacia de los controles.
e) Implementar programas de formación y de
concienciación.
f) Gestionar la operación del SGSI.
SGSI: Sistema de Gestión de la Seguridad de la Información o
g) Gestionar los recursos del SGSI. modelo formalizado con el que se gestiona la seguridad
h) Implementar procedimientos y controles para de la información. La Norma UNE-ISO/IEC 27001 define
detección y respuesta a incidentes de seguridad. este sistema de gestión.
Figura 6.6.7. Las 30 actividades de gestión de la seguridad en la Norma ISO/IEC 27001

En la figura 6.6.8 se muestra un esquema con las actividades del proceso, realizado
imitando el ya legendario esquema de gestión de la continuidad de ITIL v2.
GESTIÓN DE LA SEGURIDAD DE LA INFORMACIÓN
Creación del proceso Alcance, política y enfoque Política seguridad

• Alcance, política y enfoque Proyecto implantación
PLAN
Análisis de riesgos
Evaluación de riesgos
de seguridad
Selección de objetivos de
• Requerimientos y estrategia
control y sus controles
Declaración de
Declaración de riesgos
riesgos de seguridad
Implementación Plan tratamiento

Plan tratamiento de riesgos
y operación riesgos seguridad
DO
Implementar el plan de tratamiento de riesgos
Procedimiento incidentes seguridad Pruebas iniciales
Pruebas iniciales
Prueba de Supervisar,
Supervisión
controles monitorizar
y revisión
CHECK
Revisión y y registrar Investigar

auditoría incidentes
Actualizar
Gestionar incidentes severos de seguridad
Mantenimiento y mejora
ACT
Fuente: e.p. a partir del libro ITIL Provisión de Servicio publicado por OGC y de UNE-EN ISO 27001.
Figura 6.6.8. Enfoque de la gestión de la seguridad de la información en este libro
Siguiendo esta estructuración en dos niveles, a continuación se relacionan las acti-

vidades del proceso alineadas con lo indicado en la Norma ISO/IEC 27001.
Creación del proceso o del sistema de gestión SGSI. La primera etapa para
empezar a implantar la seguridad es la fase de creación del propio proceso de ges-
tión de la seguridad (si se está en ISO/IEC 20000) o del sistema de gestión de la
seguridad (si se está aplicando ISO/IEC 27001). La creación del proceso se realiza
en las etapas de inicio, y de requerimientos y estrategia, al igual que en la implanta-
ción de los procesos de continuidad y disponibilidad. En el inicio se establece el
entorno necesario para que comience la implantación de la gestión de la seguridad.
A partir del entorno del negocio, se determinan los requerimientos de seguridad, se
identifican los riesgos, se acuerda el tratamiento a los mismos, se establecen los
objetivos de control y se seleccionan los controles adecuados para conseguir estos
objetivos, y se realiza la declaración formal de los riesgos.
• Alcance, política y enfoque. Se concretan las directrices que debe cumplir
el proceso:
– Definir el alcance (4.2.1.a 1): se concreta el alcance y los límites del pro-
ceso en términos de las características de la actividad del negocio, de la
organización, su ubicación, sus activos y tecnología, incluyendo los deta-
lles y la justificación de cualquier exclusión del alcance.
– Definir una política de seguridad (4.2.1.b): que incluya un marco para
la fijación de objetivos y establezca una orientación general; que tenga en
cuenta los requisitos de la actividad del negocio, los requisitos legales y las
obligaciones contractuales.
– Definir el enfoque de la evaluación de riesgos de la organización
(4.2.1.c): la metodología seleccionada para la evaluación de riesgos debe
asegurar que las evaluaciones de riesgos generen resultados comparables y
reproducibles.
• Proyecto implantación. Se recomienda que la implantación de la gestión de

la seguridad se estructure en forma de proyecto, pues es un trabajo complejo
y que afecta a muchos aspectos: organizativos, procedimentales, modifica-
ciones técnicas, implantación de herramientas, etc. Se requiere la designa-
ción de un único responsable que controle toda la implementación, que se
doten los recursos necesarios y que se realice una planificación detallada de
las tareas. El proyecto de implantación asume la puesta en marcha del pro-
ceso o del SGSI, según sea el caso.
• Evaluación de riesgos. Se realiza la identificación de los riesgos de la segu-
ridad, se analizan y se determinan los niveles de riesgo. Nótese que la activi-
dad de evaluación de riesgos es similar a la realizada en el proceso de dispo-
nibilidad y de continuidad, por lo que se recomienda que se realicen de
forma conjunta o, por lo menos, integrada.
1
Entre paréntesis la referencia al epígrafe equivalente en la Norma UNE-ISO/IEC 27001.
– Identificar los riesgos (4.2.1.d): identificación de los activos, identifica-

ción de las amenazas, identificación de vulnerabilidades y determinación
del impacto que sobre los activos puede tener una pérdida de confidencia-
lidad, integridad y disponibilidad en los mismos.
– Analizar y valorar los riesgos (4.2.1.e): analizar el impacto sobre la acti-
vidad del negocio de un incidente de seguridad, evaluar la probabilidad de
que se produzcan estos fallos, estimar los niveles de riesgo y determinar si
los riesgos son aceptables.
• Selección de objetivos de control y sus controles. La Norma ISO/IEC

27001 proporciona un juego muy completo de objetivos de control, cada
uno con sus controles de seguridad asociados. Para cada control se detalla
la finalidad y las recomendaciones para su implementación. La gestión de la
seguridad está claramente orientada a la implantación de controles, que se
pueden seleccionar entre estos proporcionados u otros que se consideren
necesarios.
– Identificar y evaluar las opciones para el tratamiento de riesgos
(4.2.1.f), para cada uno de los riesgos se determina la forma de trata-
miento: si se le aplicará las medidas de salvaguardia o controles adecua-
dos, se asumirá el riesgo, se evitará el mismo o se transferirá a un ter-
cero.
– Seleccionar los objetivos de control y los controles para el trata-
miento de los riesgos (4.2.1.g): una vez identificado el tratamiento de
los riesgos, se determinan los objetivos para controlarlos. Para cada obje-
tivo de control se establecerán los controles que se consideren necesarios
para conseguir que se alcancen. Objetivos y controles se seleccionan pri-
meramente entre los contenidos en la Norma ISO/IEC 27001 y detalla-
dos en ISO/IEC 17799. Esto no quita para que se añadan otros objetivos
y sus controles asociados si se consideran necesarios. Esta selección debe
tener en cuenta los criterios de aceptación de riesgos, además de los requi-
sitos legales, reglamentarios y contractuales.
• Declaración de riesgos. Formalización y aprobación por la dirección de la

evaluación de riesgos realizada y la selección de los controles.
– Obtener la aprobación de los riesgos residuales propuestos (4.2.1.h),
por parte de la dirección.
– Obtener la autorización para implementar y operar (4.2.1.i) el pro-
ceso de gestión de la seguridad o el SGSI, por parte de la dirección.
– Elaborar una declaración de aplicabilidad – SoA 2 (4.2.1.j). Es un docu-

mento que especifica los objetivos de control y los controles de seguridad
que se utilizarán para el tratamiento de los riesgos, seleccionados entre los
propuestos por ISO/IEC 27001 y de otras fuentes. La declaración de apli-
cabilidad proporciona un resumen de las decisiones relativas al tratamiento
de los riesgos. La justificación de las exclusiones facilita una comprobación
cruzada de que no se ha omitido inadvertidamente ningún control. Se ela-
bora a partir de las opciones de tratamiento de riesgos decididas, y de la
selección realizada de los objetivos de control y sus controles asociados.
Implementación y operación. Una vez evaluados los riesgos, identificada la estra-

tegia de tratamiento para cada uno y seleccionados los objetivos de control y los
controles, se procede a la implementación del proceso de gestión de seguridad. Se
comienza con un plan para el tratamiento de riesgos, para continuar con las accio-
nes para implantar los controles y la definición de los procedimientos específicos
para incidentes de seguridad.
• Plan de tratamiento de riesgos. Dentro del plan de implantación general
de la seguridad se encuentra el plan concreto de tratamiento de riesgos, que
es un plan de implantación específico para las medidas correctoras de los
riesgos. Se centra en planificar la puesta en marcha de cada una de las opciones
definidas para el tratamiento de los riesgos, detalla especialmente la planifi-
cación para implementar los controles.
– Formular un plan de tratamiento de riesgos (4.2.2.a) que identifique
las acciones, los recursos, las responsabilidades y las prioridades adecua-
dos para gestionar los riesgos de la seguridad de la información.
• Implementar el plan de tratamiento de riesgos. Desarrollando las acciones

planificadas en el plan de tratamiento anterior, se llevan a cabo las tareas nece-
sarias para implementar cada uno de los controles seleccionados. También se
definen e implementan los indicadores para medir la eficacia de los controles.
– Implementar el plan de tratamiento de riesgos (4.2.2.b) para lograr los
objetivos de control identificados, que tenga en cuenta su financiación, y
la asignación de funciones y responsabilidades.
– Implementar los controles seleccionados (4.2.2.c): conjunto de subpro-
yectos o tareas necesarias para la puesta en marcha de los controles. Esta es
una de las actividades más extensas y costosas de la implementación de la
2
SoA, Statement of Applicability.
seguridad, pues los controles son de todo tipo, unas veces serán directrices
internas, otras la designación de funciones, otras requerirá la compra de
equipamiento o de soluciones software, puede ser necesario cambiar la con-
figuración de los sistemas, etc.
– Definir el modo de medir la eficacia de los controles (4.2.2.d): la
medición de la eficacia de los controles permite determinar hasta qué
punto los controles cumplen los objetivos de control planificados. Se
define la forma de medir la eficacia de los controles o de los objetivos
de control seleccionados, también se especifica cómo se tienen que usar
estas mediciones.
• Procedimiento de gestión de incidentes seguridad. De forma integrada

con el proceso de gestión del incidente, en este proceso especializado en la
seguridad, se desarrollan e implementan los procedimientos específicos para
la alerta temprana de este tipo de incidentes y los procedimientos de detalle
para que la respuesta sea lo más eficaz posible. Este procedimiento se debe
integrar con el resto de procedimientos generales de gestión del incidente.
– Implementar procedimientos y controles para detección y respuesta a
incidentes de seguridad (4.2.2.h) para realizar una detección temprana
de eventos de seguridad y facilitar una respuesta rápida ante cualquier
incidente de seguridad.
• Pruebas iniciales. Conjunto de pruebas que garantizan que las medidas

implementadas funcionan correctamente. Se deben realizar antes de dar por
finalizada la implementación.
• Gestionar recursos seguridad.
– Gestionar la operación de la seguridad (4.2.2.f): conjunto de activida-
des y procedimientos técnicos del día a día que permiten que los controles
implantados sigan activos.
– Gestionar los recursos de la seguridad (4.2.2.g y 5.2) que cubre tanto
la provisión de los recursos, la dotación de presupuestos para la concien-
ciación, formación y capacitación del personal.
– Implementar programas de formación y de concienciación (4.2.2.e
y 5.2.2). Es necesario formar a todo el personal al que se le hayan asignado
responsabilidades para que sea competente para llevar a cabo las tareas reque-
ridas. Mediante diversas acciones de comunicación se asegura que el resto del
personal sea consciente de la trascendencia y de la importancia de las activi-
dades de seguridad de la información y de su contribución a las mismas.
Supervisión y revisión. Una vez implantados los controles, se llevan a cabo de

forma continua un conjunto de actividades que supervisan que los controles se
mantengan activos y que la seguridad permanezca vigente.
• Revisión y auditoría. Revisiones, mediciones y auditorías internas del fun-
cionamiento de todos los aspectos de la seguridad.
– Realizar revisiones periódicas de la eficacia de la seguridad (4.2.3.b), con
el fin de comprobar que la seguridad funciona como se espera. Las revisiones
comprenden: los resultados de las auditorías de seguridad, los incidentes de
seguridad, los resultados de las mediciones de la eficacia, las sugerencias y los
comentarios de todas las partes interesadas. Estas revisiones incluyen el cum-
plimiento de la política de seguridad, de los objetivos fijados y de los contro-
les de seguridad.
– Medir la eficacia de los controles (4.2.3.c), para verificar si se están
cumpliendo los requisitos de seguridad. Como resultados de las medicio-
nes se emiten los informes asociados.
– Revisar las evaluaciones de riesgos y revisar los riesgos residuales
(4.2.3.d). Revisión de las evaluaciones de riesgos en los intervalos planifi-
cados y revisión de los riesgos residuales y los niveles de riesgo aceptables
que han sido identificados, teniendo en cuenta los cambios ocurridos
(organización, tecnología, objetivos y requisitos del negocio, amenazas,
factores externos, etc.).
– Realizar las auditorías internas (4.2.3.e) sobre la seguridad en los períodos
planificados. Las auditorías internas las lleva a cabo la propia organización o
bien se contratan externamente pero con fines de evaluación internos.
– Realizar una revisión general (4.2.3.f) del proceso de gestión de la seguri-
dad (o del SGSI) con carácter periódico, para asegurar que el ámbito de apli-
cación sigue siendo adecuado y que se revisan todos los aspectos del mismo.
• Pruebas de los controles. Una vez implantados los controles y realizada la

prueba inicial en la etapa de implementación, se deben realizar pruebas
periódicas de los controles para verificar que siguen siendo válidos y que
producen los resultados especificados de tratamiento de los riesgos. Entre
estas pruebas hay que destacar los ataques concertados o “hacking ético”, no
malicioso, con el que se intenta vulnerar la seguridad para comprobar los
puntos débiles y el funcionamiento de los controles.
• Supervisar, monitorizar y registrar. Labor permanente de la gestión ope-
rativa de la seguridad que vela de forma constante por el cumplimiento de lo
establecido y la detección temprana de los incidentes.
– Ejecutar procedimientos de supervisión y revisión (4.2.3.a), para iden-

tificar lo antes posible las debilidades del sistema de seguridad, ayudar a
detectar eventos de seguridad, determinar si las acciones tomadas para
resolver una vulneración de la seguridad han sido eficaces, etc.
– Registrar las acciones o incidentes (4.2.3.h) relacionados con la seguri-
dad, con el fin de recolectar toda la información necesaria para su evalua-
ción posterior.
• Investigar incidentes de seguridad. Se deben investigar los incidentes de

seguridad de cara a identificar las debilidades y generar las mejoras o accio-
nes correctoras adecuadas. La investigación de incidentes de seguridad se
debe registrar como un ticket de problema y se debe realizar como parte del
proceso de gestión del problema.
• Actualizar. La información, documentación, etc.
– Actualizar los planes de seguridad (4.2.3.g) teniendo en cuenta las con-
clusiones de las actividades de supervisión y revisión, los cambios en los
servicios, etc.
• Gestionar incidentes severos de seguridad. Los incidentes de seguridad se

deben gestionar por el mismo cauce que el resto de incidentes o de contin-
gencias de continuidad. En el caso de incidentes severos, se deben definir los
procedimientos específicos de actuación y es conveniente tener un conjunto
de especialistas en seguridad preparados. El tratamiento de incidentes graves
de seguridad tienen muchas similitudes con la gestión de una contingencia
de continuidad: hay una pérdida importante en los servicios de TI, se debe
gestionar soluciones alternativas, movilizar los medios de recuperación, ges-
tionar la comunicación exterior, etc. En ciertas organizaciones, se tiene pre-
parada una sala o un centro especializado en la gestión de estos incidentes
graves de seguridad. En otras ocasiones se integra en la sala de crisis para la
gestión de todo tipo de incidentes graves.
Mantenimiento y mejora del proceso o del SGSI. Como en todo proceso se

debe contemplar la mejora continua del mismo. A este respecto, ISO/IEC 27001
establece las actividades siguientes:
• Implementar las mejoras identificadas (4.2.4.a).
• Aplicar las medidas correctivas y preventivas adecuadas (4.2.4.b).
• Comunicar las acciones y mejoras a todas las partes (4.2.4.c).
• Asegurar que las mejoras alcancen los objetivos previstos (4.2.4.d).
El enfoque dado al proceso en ITIL v3 es de concepción muy similar al de

ISO/IEC 27001, aunque mucho menos detallado. También se basa en una política
de seguridad de la información, en un sistema de gestión de la seguridad para
implementar el proceso, en una estructura organizacional, en unos controles, en
comunicación, en formación, en concienciación, etc. El proceso se plantea en
aspectos más allá de los puramente técnicos. En la figura 6.6.9 se muestra el enfo-
que que se da en ITIL v3 para este proceso.
Enfoque del proceso en ITIL v3 muy similar a 27001 Actividades de gestión de la seguridad en ITIL v3
El proceso consiste principalmente en: • Producir y mantener una política de seguridad de la

• Un política de seguridad de la información que información.
conduce a la estrategia, los controles y la regulación. • Evaluar y categorizar los activos de información y
• Un sistema de gestión de la seguridad (SGSI) vulnerabilidades.
conteniendo normativa, procedimientos de gestión • Imponer y revisar controles de seguridad, revisión
y directrices. e implementación de mitigación del riesgo.
• Una estrategia clara de seguridad ligada a los • Comunicar, implementar e impulsar la adhesión a
objetivos de negocio. todas las políticas de seguridad.
• Informar, revisar y reducir las vulnerabilidades de
• Una estructura organizacional de seguridad.
seguridad y los incidentes mayores.
• Un conjunto de controles que soporte la política. • Periódicamente evaluar, revisar e informar los riesgos
• Procedimientos de supervisión que aseguren el y amenazas de seguridad.
cumplimiento y proporcionen información sobre • Supervisar y gestionar incidentes y vulnerabilidades
la efectividad. de seguridad.
• Una estrategia y plan de comunicación para la
seguridad.
• Una estrategia y plan de formación y concienciación.
Figura 6.6.9. Planteamiento de la gestión de la seguridad en ITIL v3
La política de seguridad de la información

La política de seguridad de la información es un documento en el que la dirección
realiza una declaración formal estableciendo los objetivos generales de seguridad a
alcanzar por la organización. Debe ser el punto de partida que desencadena y marca
el contexto para la implantación de este proceso.
La política de seguridad de la información debería contemplar de manera explícita:
• El objeto de la misma, el alcance y el marco jurídico.
• La organización y responsabilidades, y la aplicación de la misma.
• La evidencia del compromiso de la dirección en materia de seguridad.
• El aseguramiento de la confidencialidad, disponibilidad e integridad de la

información derivada de los servicios prestados.
• La referencia al desarrollo posterior de los procesos y procedimientos que la
respaldan.
• La referencia a la mejora continua de la seguridad en la organización.
• La potenciación de la concienciación, formación y motivación del personal
de la empresa u organización.
• El compromiso del cumplimiento de la legislación vigente en materia de
seguridad.
• El compromiso de establecer objetivos específicos en materia de seguridad.
• Su difusión a todo el personal de la empresa u organización.
• Su revisión periódica o siempre que haya cambios significativos en la
empresa u organización.
En la figura 6.6.10 se muestra un enfoque para este documento.
Política de seguridad de la información
• Objeto, alcance, marco, jurídico y vigencia. Para velar por el cumplimiento

de la política, promueve la
• Organización y responsabilidades.
existencia de:
• Compromiso de la dirección.
• Un responsable de seguridad.
• Compromiso de establecer objetivos específicos en
materia de seguridad. • Un comité de seguridad.
• Políticas relativas a: control de accesos, control de

contraseñas, antivirus, correo electrónico, Internet, Responsable
clasificación de la información, acceso remoto, de seguridad
acceso de suministradores, etc.
• Desarrollo posterior de los procesos y procedimientos.
• Mejora continua de la seguridad en la organización. Comité de
• Confidencialidad, disponibilidad e integridad de la seguridad
información en los servicios prestados.
• Potenciar la concienciación, formación y motivación del
personal de la organización.
• Compromiso con el cumplimiento de la legislación
vigente en materia de seguridad.
• Debe ser difundida a todo el personal de la empresa u
organización.
• Revisión de la política. Fuente: Telefónica y Libro ITIL Provisión
de Servicio publicado por OGC.
Figura 6.6.10. Contenidos de la política de seguridad de la información

La Norma ISO/IEC 20000-1 establece el requisito claro de la existencia de la polí-

tica de seguridad y la necesidad de que sea difundida al personal de TI e incluso a
los usuarios de los servicios de TI.
UNE-ISO/IEC 20000-1
La dirección, con la autoridad apropiada, debe aprobar una política de seguridad
de la información, que debe comunicarse a todo el personal implicado y, cuando
sea adecuado, a los clientes.
La política de seguridad es un documento de alto nivel firmado habitualmente por

el presidente, el consejero delegado o el cargo de mayor nivel en la empresa u orga-
nización. Una vez firmado, debe publicarse en diferentes medios, como, por ejem-
plo, la intranet de la empresa, y su contenido tiene que divulgarse. También debe
extenderse a todos los empleados, pues deberán seguir en sus actividades diarias los
preceptos que se indican en la misma.
El comité de seguridad
La política de seguridad conviene que esté respaldada por un órgano interno en el
que se traten todas las cuestiones que precisen de la intervención de la dirección,
además de servir como instrumento que ejecuta el compromiso con la seguridad de
la información.
El comité de seguridad, por su composición, se convierte en el asesor del responsa-
ble de seguridad para las decisiones de mayor nivel en la organización en los asun-
tos relacionados con la seguridad de la información. Al frente del mismo se encuen-
tra el responsable del proceso de seguridad. El comité se debería reunir con una
periodicidad mínima mensual. El resultado de las reuniones de este comité deberá
quedar reflejado en unas actas de reunión.
El comité de seguridad se responsabiliza de:
• El asesoramiento al responsable de seguridad.
• La comunicación a toda la organización de la importancia de cumplir tanto
los requisitos de la norma como los legales y reglamentarios.
• La evolución de la política y objetivos de la seguridad.
• El aseguramiento de la disponibilidad de presupuestos y recursos adecuados.
• La aprobación y respaldo ejecutivo a los planes de implantación y de trata-
miento de riesgos de la organización.
• Que se realicen todas las actividades del proceso, desde la creación, hasta el
mantenimiento y mejora.
• La revisión de los temas de seguridad más relevantes para la empresa u orga-
nización.
Evaluación de riesgos
Es recomendable que la evaluación de riesgos de seguridad y su tratamiento esté
basada en alguna de las metodologías existentes relacionadas con esta materia,
como por ejemplo, CRAMM, NIST, Magerit, etc. Cada organización puede deci-
dir utilizar la metodología que considere más adecuada.
ISO/IEC 20000-2 recomienda además que la evaluación de riesgos se realice con
una periodicidad, que se registre, que se mantenga actualizada con los cambios, etc.
UNE-ISO/IEC 20000-2
Prácticas para la evaluación de Seguridad y disponibilidad de

los riesgos de seguridad la información
La evaluación de los riesgos de seguri- Al evaluar los riesgos, se debería pres-
dad debería: tar atención a los siguientes puntos:
a) ser realizada con una periodici- a) revelación de información sensi-
dad acordada; ble a partes no autorizadas;
b) ser registrada; b) información inexacta, incompleta
o inválida (por ejemplo: informa-
c) ser mantenida durante los cam-
ción fraudulenta);
bios (cambios de las necesidades
del negocio, de procesos o de c) información que quede inservible
configuraciones); para su uso (por ejemplo: debido
a un corte de energía eléctrica);
d) ayudar a entender en qué podría
impactar uno de los servicios ges- d) daño físico o destrucción de los
tionados; equipos necesarios para proveer
e) proveer de información para las los servicios.
decisiones referentes a los tipos También se deberían tener en cuenta los
de controles a establecer. objetivos de la política de seguridad de la
información, las necesidades para satisfa-
cer los requisitos específicos de los clien-
tes respecto a la seguridad (por ejemplo:
niveles de disponibilidad) y los requisitos
legales o regulatorios que apliquen.
En la evaluación de riesgos se realiza la identificación de los riesgos, y el análisis y

valoración de los mismos. A su vez, cada una de estas actividades está formada por
tareas más detalladas:
• Identificar los riesgos:
– Identificación de los activos.
– Identificación de las amenazas.
– Identificación de las vulnerabilidades.
– Determinación del impacto sobre los activos.
• Analizar y valorar los riesgos:

– Análisis del impacto sobre la actividad del negocio.
– Evaluación de la probabilidad de ocurrencia.
– Estimación de los niveles de riesgo.
– Determinación de si los riesgos son aceptables.
Identificación de los activos o elementos de configuración. Inicialmente se

deben identificar todos aquellos elementos de configuración empleados en el fun-
cionamiento de las infraestructuras y servicios prestados a clientes, así como, la pro-
pia información gestionada de su uso. La identificación de los activos desemboca
en un inventario detallado de los mismos. En la identificación se realiza también su
clasificación en cuanto a su criticidad o importancia para el funcionamiento de los
servicios. También se debe identificar al propietario de cada uno, o responsable de
su protección y funcionamiento. Si se ha implantado el proceso de gestión de la
configuración (véase el capítulo 9 de este libro), esta actividad ya se habrá realizado
y únicamente habrá que complementar los inventarios con la información que se
precisa para la seguridad.
ISO/IEC 20000-2 es clara en sus recomendaciones al respecto.
UNE-ISO/IEC 20000-2
Identificación y clasificación de los

activos de información ordenadores, sistemas de comuni-
cación, equipos del entorno, docu-
El proveedor del servicio debería: mentos y otra información) que
a) mantener un inventario de los acti- son necesarios para la provisión
vos de información (por ejemplo, del servicio;
b) clasificar cada activo de acuerdo c) la responsabilidad para la protec-

con su criticidad para el servicio y ción de los activos debería recaer
el nivel de protección que éste en el propietario de dichos acti-
requiera, así como nombrar a un vos, aunque estos pueden delegar
propietario que sea el responsable las responsabilidades de la ges-
de proporcionar dicha protección; tión diaria de la seguridad.
La estructura lógica de estos inventarios de activos, realizados desde la perspectiva

de la seguridad, debe estar perfectamente alineada con la base de datos de la confi-
guración (CMDB). La información sobre los activos o elementos de configuración
identificados se deben incluir en la CMDB o en inventarios específicos. Según las
necesidades de cada organización, este inventario para seguridad, puede contener
las siguientes categorías:
• Hardware. Servidores, almacenamiento, equipos de comunicación, ordena-
dores personales, impresoras, etc.
• Software. Aplicaciones que forman los servicios de TI, productos y paquetes
software, herramientas, software ofimático, etc.
• Documentación. Organizativa, operativa técnica, etc.
• Servicios. Servicios de TI, servicios internos, servicios de terceros, etc.
• Activo de información. Bases de datos, archivos que contienen datos per-
sonales, manuales de usuarios, material de formación, procedimientos de tra-
bajo, planes de continuidad, contratos, documentación de la organización,
correos electrónicos, etc.
• Contratos. SLA o acuerdos con clientes, OLA o acuerdos internos, UC o
contratos con suministradores.
• Personas. Personal de TI, directivos de la empresa, personal subcontratado,
personas de contacto de suministradores, de vigilantes de seguridad, perso-
nal de servicios, personal de limpieza, etc. A efectos de la gestión de la segu-
ridad de la información, puede ser necesario tener una relación exhaustiva de
personas propias o ajenas que habitualmente tienen acceso a las instalaciones
y sistemas de la empresa.
• Localizaciones. Edificios, centros de datos, sistemas de climatización, siste-
mas de alimentación eléctrica, sistemas de detección de incendios etc.
En la identificación de activos se realiza una valoración de cada uno en relación a:

• La criticidad del activo para la organización.
• La criticidad del activo para los servicios de TI.

• El nivel de protección requerido para mantener la integridad, confidenciali-
dad y disponibilidad de la información.
A partir de esta valoración, se le asigna a cada activo o elemento de configuración

un nivel que determina su importancia para los servicios de TI y, por tanto, para el
negocio:
• Importancia alta. El activo interviene en procesos clave para la organiza-
ción (necesarios y suficientes) y su no disponibilidad puede poner en peligro
la continuidad del negocio.
• Importancia media. El activo interviene en los procesos de apoyo a los
esenciales de la organización. Su indisponibilidad puede retrasar un determi-
nado proceso pero no se vería afectada la continuidad del negocio.
• Importancia baja. El activo interviene en procesos que no están directa-
mente relacionados con el negocio, aunque sí son necesarios. Su no disponi-
bilidad causa algún contratiempo pero en ningún caso se vería afectada la
continuidad del negocio.
La importancia otorgada a cada uno de los activos se reflejará también en el inven-

tario de activos.
Identificación de las amenazas. El siguiente paso dentro de la evaluación de ries-

gos es identificar todas las amenazas sobre los activos o elementos de configura-
ción. Las amenazas pueden provenir de distintas fuentes, como por ejemplo:
• Del entorno. Sucesos exteriores a la organización que pueden afectar a los
servicios: eventos de carácter natural, interrupciones de los servicios exter-
nos, factores climatológicos, etc.
• Humanas. Sucesos en los que hay una intervención humana negligente,
intencionada o deliberada.
• Fallos técnicos. Derivados de algún tipo de fallo en equipos, en programa-
ción, en instalaciones, en infraestructuras o del uso de las mismas.
UNE-ISO/IEC 20000-2
Riesgos para los activos de

a) su naturaleza (por ejemplo: fun-
información
cionamiento defectuoso del soft-
Los riesgos para los activos de informa- ware, errores de operación, fallos
ción se deberían evaluar en función de: de comunicación);
b) probabilidad; d) experiencias pasadas.

c) impacto potencial para el negocio;
Se lleva a cabo un análisis de las amenazas que pueden derivarse de cada una de
estas fuentes, en función de los activos existentes en la organización, los procesos y
servicios prestados, la posición en el mercado, el tipo de clientes y los antecedentes.
Las amenazas se irán reflejando en el análisis de riesgos, detallándose:
• Tipo de amenaza. Por ejemplo, robo de información.
• Motivo. Se indican los motivos que pueden provocar que una amenaza se
materialice.
• Resultado (ataque o incidente). Se indican las consecuencias que tendría
para la organización cada una de las amenazas en caso de materializarse. Los
resultados tendrán alguna de las siguientes consecuencias sobre la informa-
ción: visualización, modificación, destrucción o pérdida, e interrupción.
Identificación de las vulnerabilidades. En función de las amenazas, y para poder

valorar su importancia, se tendrán en cuenta las vulnerabilidades o debilidades que
puedan existir. Las amenazas para ser consideradas como tal, habrán de tener aso-
ciadas una vulnerabilidad. Al mismo tiempo, estas vulnerabilidades han podido ser
detectadas en la actividad de identificación de activos.
La identificación de vulnerabilidades se realiza a través de un análisis exhaustivo de
cada uno de los activos. La información de este análisis podrá ser completada con
listados de vulnerabilidades, con el asesoramiento de expertos en seguridad o con
la información proporcionada por los propios proveedores de los activos (en los
casos que se trate de recursos materiales). En la identificación de vulnerabilidades
se tendrán en cuenta:
• La política de seguridad.
• Los procedimientos de seguridad (si existiesen en ese momento).
• Los requerimientos de los sistemas.
• Los controles o salvaguardias técnicas implantadas.
• Los chequeos de vulnerabilidades anteriores.
• Las auditorías de conformidad técnica realizadas.
Determinar el impacto sobre los activos. Con el conocimiento de los activos, de

las amenazas y de las vulnerabilidades, se determina a nivel de cada activo el posible
impacto en él si se materializase la amenaza. El impacto de la amenaza en el activo

se valora teniendo en cuenta la pérdida, y la degradación del activo, considerando
las consecuencias:
• Pérdida de integridad. La integridad del sistema o de los datos se pierde.
• Pérdida de disponibilidad. Implica la imposibilidad de que el activo pueda
realizar su función.
• Pérdida de confidencialidad. La información que gestiona el activo queda
expuesta y desprotegida.
Analizar el impacto sobre la actividad del negocio. Consiste en determinar y

cuantificar las consecuencias que sobre el negocio tendría cada una de las amenazas
en caso de materializarse, es decir, el ataque o incidente identificado en el análisis
de riesgos. En función de las consecuencias se establecerá el nivel de impacto, que
podrá ser:
• Impacto alto. Se provoca una pérdida elevada, afecta a los activos de mayor
valor. Impacta no sólo a los procesos críticos de la organización sino también
a su misión o la imagen que se da al exterior. También puede provocar daños
o víctimas humanas. Se deben cuantificar las posibles pérdidas.
• Impacto medio. Se provoca una pérdida media. Deberá estar cuantificado.
• Impacto bajo. Puede provocar la pérdida de algún activo no muy impor-
tante. Deberá estar cuantificado.
El nivel de impacto se refleja y justifica en el análisis de riesgos.
Evaluar la probabilidad de ocurrencia. A la hora de determinar la probabilidad

de que una amenaza se materialice se deberán tener en cuenta:
• La motivación y capacidad del origen de la amenaza.
• El tipo de vulnerabilidad
• Los controles o salvaguardias existentes
En función de las consideraciones anteriores se determina la probabilidad de

ocurrencia de un riesgo. En todos los casos es recomendable cuantificar la pro-
babilidad en forma de porcentaje. Como mínimo la probabilidad se clasificará
como:
• Probabilidad alta. Si el origen de la amenaza tiene una motivación clara y
tiene capacidad para actuar. No existen salvaguardias adecuadas.
• Probabilidad media. El origen de la amenaza está motivado y tiene capaci-

dad para actuar. Existen salvaguardias adecuadas.
• Probabilidad baja. El origen de la amenaza no está motivado o no tiene
capacidad para actuar. Existen salvaguardias.
La probabilidad de que una amenaza se materialice también estará reflejada en el

análisis de riesgos.
Estimar los niveles de riesgo. En el siguiente paso se determina el nivel de riesgo

para cada una de las amenazas. El riesgo estará cuantificado, calculado en base a la
probabilidad de que la amenaza se materialice y por el impacto que ésta puede lle-
gar a tener en la empresa u organización, teniendo en cuenta los controles o salva-
guardas existentes. El riesgo se clasifica como:
• Riesgo alto. Existe una gran necesidad de medidas correctivas (controles)
que deben articularse en un plan.
• Riesgo medio. Son necesarias medidas correctivas (controles) que se incor-
porarán a un plan para ser ejecutadas en un plazo de tiempo razonable.
• Riesgo bajo. Será necesario determinar qué medidas correctivas (controles)
son necesarias, o bien aceptar el riesgo.
El riesgo es una función de la probabilidad y del impacto (véase la figura 6.6.11).
Riesgo Impacto
Probabilidad Alto Medio Bajo
Alta Alto Medio Bajo
Media Medio Medio Bajo
Baja Medio Bajo Bajo
Figura 6.6.11. Cálculo del riesgo en función de la probabilidad y del impacto
El nivel del riesgo se refleja en el análisis de riesgos. Se calcula como el resultado de

multiplicar el valor de la probabilidad de que la amenaza se materialice por el valor
del impacto que dicha amenaza tendría para la organización.
El nivel de riesgo de cada amenaza deberá cruzarse con cada uno de los activos. De
este modo se conoce el riesgo total soportado por cada uno de los activos. Este
riesgo total es ponderado en función de la importancia dada al activo en el
momento de su identificación. Para cada uno de los activos se tendrá un nivel de
riesgo ponderado.
Determinar si los riesgos son aceptables. Con los valores de los riesgos calculados
se determinan los riesgos asumibles por la organización y los que no son aceptables.
Con la determinación de los riesgos aceptables termina la evaluación de riesgos.

A partir de esta información deberá iniciarse la fase de tratamiento del riesgo.
Identificación y evaluación de las opciones de

tratamiento de riesgos
Tras la evaluación de riesgos se pasa a la actividad de identificar y evaluar las
diferentes opciones para el tratamiento de riesgos. El primer paso es definir el
umbral del riesgo, es decir, cuándo se considera que el nivel de riesgo obtenido
es aceptable, y por tanto, únicamente se vigilarán las condiciones para mante-
ner el nivel obtenido. También se define cuándo el riesgo no es aceptable, en
cuyo caso será necesario seleccionar e implantar controles de seguridad para
cambiar el valor del riesgo. Esta decisión se reflejará posteriormente en una
declaración formal por parte de la dirección (declaración de riesgos o de apli-
cabilidad) y en ella se establece tanto el umbral del riesgo efectivo como el del
riesgo residual.
El nivel de riesgo aceptable es la resultante del equilibrio entre el coste de seguri-
dad (coste de los controles de seguridad) y el coste del riesgo (coste que tendría si
el riesgo se hiciera realidad).
A partir de los resultados de la evaluación de riesgos, y teniendo en cuenta el
nivel de riesgo aceptable establecido para la empresa, el responsable de seguri-
dad, junto con el responsable del activo afectado, identifican aquellos controles o
salvaguardias que le protejan efectivamente contra los riesgos identificados y los
no aceptables. Para cada riesgo se evalúan las posibles alternativas que son las
siguientes.
• Reducir el riesgo (reducir amenazas, vulnerabilidades, posibles impactos,
etc.) implantando los controles apropiados.
• Asumir el riesgo.
• Evitar el riesgo.
• Transferir el riesgo a terceros (seguros, proveedores, etc.).
Selección de los objetivos de control y sus controles

Para cada uno de los riesgos identificados como no aceptables, se identifican los
objetivos de control y los controles adecuados. Inicialmente se seleccionan entre
los propuestos en ISO/IEC 27001, añadiendo posteriormente los que se conside-
ren necesarios y que no estén incluidos en la norma.
Estos controles van orientados a la reducción del nivel de riesgo existente, de tal
manera que el nivel total de riesgo soportado por la organización sea menor al fina-
lizar el período de implantación.
Sobre los riesgos identificados como aceptables también se podrán establecer obje-
tivos o se podrán incluir en los planes de gestión del riesgo y contingencia, pero la
organización puede determinar no trabajar específicamente en mitigarlos.
En ISO/IEC 20000-1 se requiere que se trabaje con controles de seguridad para
implementar la política de seguridad y gestionar los riesgos. Además, se deberán
documentar los controles implementados y se tendrá que evaluar previamente el
impacto de los cambios sobre los mismos.
UNE-ISO/IEC 20000-1
Los adecuados controles de seguridad deben ayudar a:

a) implementar los requisitos de la política de seguridad de la información;
b) gestionar los riesgos asociados al acceso al servicio o a los sistemas.
Los controles de seguridad deben estar documentados. La documentación debe des-

cribir los riesgos a los que están asociados los controles, la manera de utilizarlos y el
mantenimiento de los mismos.
El impacto de los cambios sobre los controles se debe evaluar antes de que los cam-
bios sean implementados.
Los controles se asocian a cada uno de los riesgos con el nivel de detalle necesario.
La selección de controles debe:
• Evaluar y seleccionar los controles. En función de los controles seleccio-

nados a priori, antes de proceder a su implantación, hay que tener en cuenta
la capacidad de adaptación, compatibilidad y eficiencia que éstos tienen.
• Analizar su viabilidad económica. Otro elemento que se debe tener en
cuenta es la viabilidad económica de cada uno de los controles seleccionados.
Se realizará una valoración económica aproximada de los costes que tendría
su implantación.
• Priorización de los controles. Dado que todos los controles no se podrán
implantar a la vez, es necesario establecer un orden de implantación en fun-
ción del riesgo, del plazo y del coste.
Estos controles se implementarán a través del plan de tratamiento de riesgos.

La Norma ISO/IEC 27001 establece los objetivos de control en torno a 7 áreas de
gestión de la seguridad. En la figura 6.6.12 se muestran estas áreas.
Figura 6.6.12. Áreas de gestión de la seguridad en ISO/IEC 27001

y el apartado en el que se tratan en la norma
Para cada una de estas áreas de gestión de la seguridad se establecen sus objetivos
de control. Para cada objetivo de control se establece un conjunto posible de con-
troles. En ISO/IEC 27001 se propone un total de 39 objetivos de control y 133
controles. En la figura 6.6.13 se muestra un ejemplo de este contenido.
Objetivos de control y controles en UNE-ISO/IEC 27001 Actividades de gestión de la seguridad en ITIL v3
Área: 10 Gestión de comunicaciones y operaciones. Guía de implementación:

10.1 Responsabilidades y procedimientos de La segregación de las tareas es un método
operación. para reducir el riesgo de un mal uso accidental o
10.1.1 Documentación de los procedimientos de deliberado del sistema. Se debiera tener cuidado
operación. que nadie pueda tener acceso, modificar o
utilizar los activos sin autorización o detección.
10.1.2 Gestión de cambios.
Se debería separar la iniciación de un evento
10.1.3 Segregación de tareas. de su autorización. Se debería considerar la
posibilidad de colisión en el diseño de los
Control: Las tareas y áreas de responsabilidad
controles.
deben segregarse para reducir la posibilidad de
que se produzcan modificaciones no autorizadas Las organizaciones pequeñas pueden encontrar
o no intencionadas o usos indebidos de los difícil de lograr la segregación de las tareas,
activos de la organización pero se debería aplicar el principio mientras
sea posible y practicable. Cuando es difícil de
10.1.4 Separación de los recursos de desarrollo, segregar, se deberían considerar otros controles
prueba y operación. como la supervisión de actividades, rastros de
10.2 Gestión de la provisión de servicios por terceros. auditoría y supervisión gerencial. Es importante
que la auditoría de seguridad se mantenga
10.3 Planificación y aceptación del sistema. independiente.
10.4 Protección contra código malicioso y descargable.
10.5 Copias de seguridad.
10.6 Gestión de la seguridad de las redes.
10.7 Manipulación de los soportes.
…
Figura 6.6.13. Ejemplo de los controles en las

Normas ISO/IEC 27001 e ISO/IEC 17799
Además de los controles seleccionados de ISO/IEC 27001, también se deberán

tener en cuenta los 8 controles recomendados en ISO/IEC 20000-2.
UNE-ISO/IEC 20000-2
Controles una buena práctica en gestión de la

Además de otros controles que puedan seguridad de la información:
ser justificables y aconsejados en esta a) la alta dirección debería definir la
parte de la Norma ISO/IEC 20000 (por política de seguridad de la infor-
ejemplo: en la continuidad del servicio), mación, comunicarla a su perso-
los proveedores del servicio deberían nal y a sus clientes y asegurarse
aplicar los siguientes controles como de que se implanta eficazmente;
b) los roles y las responsabilidades e) todo el personal debe ser con-

para la gestión de la seguridad de cienciado acerca de la política de
la información se deberían definir seguridad de la información;
y asignar a un puesto de trabajo; f) debería haber apoyo de expertos
c) un representante del equipo de en la evaluación de riesgos y en la
dirección (el rol puede ser desem- implementación de los controles;
peñado por un propietario que g) los cambios no deberían compro-
sea un responsable senior) debe- meter la operación efectiva de los
ría supervisar y mantener la efica- controles;
cia de la Política de Seguridad de h) se debería hacer un informe de
la Información; los incidentes de seguridad de la
d) el personal que ejerza un rol sig- información siguiendo los proce-
nificativo en seguridad debería dimientos de gestión del incidente
recibir formación en seguridad de y, también, se debería iniciar una
la información; respuesta a dichos incidentes.
En relación al acceso de terceros u organizaciones externas (suministradores, clien-

tes externos, etc.) a los sistemas de información, en ISO/IEC 20000-1 se establece
claramente que debe existir un acuerdo formal que regularice los aspectos relacio-
nados con la seguridad.
UNE-ISO/IEC 20000-1
Los servicios que impliquen el acceso de organizaciones externas a los sistemas de

información y a los servicios, deben estar basados en un acuerdo formal que defina
todos los requisitos de seguridad necesarios.
Este mismo tema de terceros está desarrollado también en ISO/IEC 27001 (véase
el apartado A.6.2 “Terceros”) que establece como objetivo “mantener la seguridad
de la información de la organización, así como la de los dispositivos de procesado
de la información que son objeto de acceso, tratamiento, comunicación o gestión
por terceros”.
Elaborar una declaración de riesgos o de aplicabilidad

(SoA, Statement of Applicability)
La declaración de riesgos o de aplicabilidad es un documento formal, aprobado por
la dirección, que proporciona un resumen de las decisiones relativas al tratamiento
de los riesgos. Una declaración de aplicabilidad debe incluir:
• Los umbrales de riesgo asumibles por la organización.
• Los objetivos de control y los controles seleccionados y las justificaciones de
su selección.
• Los objetivos de control y los controles actualmente implementados.
• La exclusión de cualquier objetivo de control y control de ISO/IEC 27001 y
la justificación de esta exclusión. La justificación de las exclusiones facilita
una comprobación cruzada para no omitir inadvertidamente ningún control.
Plan de tratamiento de riesgos (RTP, Risk Treatment Plan)

La implantación de los controles tiene complejidad bastante diversa e implica a
muchas partes de la organización. Por ello, se llevará a cabo de una forma organi-
zada y controlada desde un punto centralizado y con enfoque de proyecto. El plan
de tratamiento de riesgos desempeña está misión. Este plan se elabora con una
periodicidad anual y debe ser aprobado por la dirección.
Los puntos que contendrá el plan serán los siguientes:
• Riesgos tratados.
• Objetivos de control que se deben implantar.
• Controles que se deben implantar.
• Plan de fechas de implantación.
• Criterios de aceptación o rechazo.
• Responsable del plan y de cada uno de sus apartados.
• Recursos asignados.
• Etc.
El responsable de seguridad también es el encargado de la modificación del plan

de tratamiento de riesgos en el caso de que cambien las condiciones en las que se
desarrolla la actividad de la empresa u organización, o hubiera cambios en la evalua-

ción de riesgos, o se produzcan modificaciones en los requisitos legales u otros requi-
sitos aplicables. En estos casos, el responsable de seguridad debe comunicar a la direc-
ción las modificaciones introducidas presentando un nuevo plan para su aprobación.
Tanto los resultados como las acciones llevadas a cabo se deben comunicar a la
dirección con carácter anual. Adicionalmente, el responsable de seguridad debe
mantener informada continuamente a la dirección, comunicándole, siempre que
crea necesario, los resultados negativos obtenidos durante el seguimiento, y el
estado de los controles y su eficacia en la reducción de los riesgos para poder tomar
una decisión a tiempo.
Gestión de incidentes de seguridad

Un incidente de seguridad de la información es un suceso o una serie de sucesos
que indican una posible brecha en el blindaje proporcionado por los controles, con
una probabilidad elevada de comprometer las operaciones del negocio y amenazar
la seguridad de la información.
Los incidentes de seguridad deben ser tratados según las actividades y tareas des-
critas en el proceso de gestión del incidente (véase el capítulo 8). Un incidente de
seguridad tiene el mismo ciclo de vida que cualquier otro incidente: comienzo del
incidente, detección y registro, clasificación y soporte inicial, asignación y escalado,
investigación y diagnóstico, reparación y recuperación, y cierre del incidente.
La Norma ISO/IEC 20000-1 requiere algunas particularidades específicas relativas
a los incidentes de seguridad: cuantificar y monitorizar los diferentes tipos de inci-
dentes de seguridad, medición de cantidades de estos y el impacto causado. Como
es habitual, las acciones de mejora se deben registrar e incorporar al plan de mejora
del servicio.
UNE-ISO/IEC 20000-1
Los incidentes de seguridad se deben comunicar y registrar tan pronto como sea
posible de acuerdo a los procedimientos de gestión del incidente. Se deben poner
en marcha procedimientos para asegurar que todos los incidentes de seguridad son
investigados, y que se toman medidas al respecto.
Se deben poner en marcha mecanismos para poder cuantificar y monitorizar los
tipos, volúmenes e impacto de los incidentes y el mal funcionamiento de la seguri-
dad. Las acciones de mejora identificadas durante este proceso se deben registrar y
servir como información de entrada al plan de mejora del servicio.
El responsable del proceso de seguridad de la información debe asegurar que todos

los incidentes de seguridad son correctamente notificados, registrados, resueltos y
cerrados. Deberá llevarse un registro de los incidentes de seguridad. Por ejemplo,
se pueden parametrizar las herramientas de gestión del servicio relacionadas con
los incidentes, para que se puedan notificar incidentes “de seguridad”, que deberán
ser gestionados, en la medida de lo posible, por personal con conocimientos en
materia de seguridad, o por lo menos, seguir las pautas y recomendaciones que
dicho personal pueda indicar.
Los procedimientos de seguridad deben estar claramente identificados y marcarán
las pautas a seguir en caso de un incidente de seguridad.
Conviene tener presente que los incidentes de seguridad, además de afectar a
la prestación del servicio de TI, también pueden comprometer la imagen de la
empresa u organización. En algunos casos, será necesario tratarlos como una con-
tingencia, siendo necesario activar la gestión de contingencias del proceso de ges-
tión de la continuidad.
Documentación y registros de seguridad

Un registro de seguridad es una información relativa a un aspecto o un evento de
la seguridad que se almacena de una forma controlada. Son necesarios para poder
realizar las auditorías y seguimientos (auditabilidad).
El proceso de gestión de la seguridad requiere poner un énfasis especial en la for-
malización de la documentación generada por el propio proceso y en registrar
formalmente ciertas actividades (medición de la eficacia, tendencias, los accesos a la
información y activos, etc.).
UNE-ISO/IEC 20000-2
Documentos y registros
Los registros se deberían analizar perió- c) dar entrada de información a un
dicamente para proporcionar informa- plan de mejora del servicio;
ción a la dirección en cuanto a: d) tener bajo control el acceso a la
a) la eficacia de la política de segu- información, los activos y los sis-
ridad de la información; temas.
b) las tendencias que aparezcan en La gestión de la seguridad de la infor-
los incidentes en seguridad de la mación debería estar documentada de
información; una manera fiable.
En relación a los registros, la Norma ISO/IEC 27001 establece unos controles

específicos:
• Se deben realizar registros de auditoria de las actividades de los usuarios, de
las excepciones y de los eventos de seguridad de la información, y se deben
mantener estos registros durante un período acordado para servir como
prueba en investigaciones futuras y en la supervisión del control de acceso
(véase el control A.10.10.1 “Registro de auditorías”).
• Los dispositivos de registro y la información de los registros se deben prote-
ger contra manipulaciones indebidas y accesos no autorizados (véase el con-
trol A.10.10.3 “Protección de la información de los registros”).
• Se deben registrar las actividades del administrador del sistema y de la ope-
ración del sistema (véase el control A.10.10.4 “Registros de administración
y operación”).
• Los fallos se deben registrar y analizar y se deben tomar las correspondientes
acciones (véase el control A.10.10.5 “Registro de fallos”).
La documentación debe incluir las decisiones de la dirección junto con los registros
de las mismas, debiendo quedar constancia de que las acciones dan respuesta a las
decisiones y a las políticas adoptadas, y garantizando que dichos documentos y los
correspondientes registros están disponibles (véase el apartado 4.3 de la Norma
UNE-ISO/IEC 27001).
La gestión de la seguridad se puede implementar como un proceso más dentro del
sistema de gestión del servicio de TI (SGSTI) o en base a un sistema de gestión
específico para la seguridad (SGSI). De cara a simplificar y mantener una coheren-
cia, todos los modelos de gestión relativos a TI deberán implementarse bajo el
paraguas formal del sistema de gestión de la calidad definido en la Norma ISO
9001. En la figura 6.6.14 se muestra esta tendencia a la unificación de los sistemas
de gestión en TI (véase el capítulo 3).
La documentación del SGSI debe incluir (véase el apartado 4.3 de la Norma UNE-
ISO/IEC 27001):
• Las declaraciones documentadas de la política y de los objetivos del SGSI.
• El alcance del SGSI.
• Los procedimientos y mecanismos de control que soportan al SGSI.
• Una descripción de la metodología de evaluación de riesgos.
• El informe de evaluación de riesgos.
Tecnologías de la información – Sistema de gestión integrado

Gestión y operación Desarrollo de SW
SG de otras áreas Gobierno Seguridad
del servicio de TI Madurez +
de la empresa SG GOB SGSI
SGSTI SG DES. SW
ISO/IEC ISO/IEC
20000 27001
Figura 6.6.14. Tendencia a la unificación de los sistemas de gestión
• El plan de tratamiento de riesgos.

• Los procedimientos documentados que necesita la organización para asegu-
rar una correcta planificación, operación y control de sus procesos de seguri-
dad de la información, y para describir cómo medir la eficacia de los contro-
les.
• Los registros requeridos por esta norma internacional.
• La declaración de aplicabilidad.

La gestión de la seguridad, al igual que el resto de los procesos, necesita un con-
junto de métricas o indicadores que permitan seguir la efectividad de los controles
implantados, los niveles de seguridad alcanzados o la eficiencia del propio proceso.
Asimismo, es necesario elaborar informes que permitan realizar el seguimiento de
las acciones emprendidas y dar a conocer los resultados del proceso. Las métricas
más destacadas para este proceso son las siguientes.
• Número de incidentes de seguridad ocurridos en el período de medición.
• Número de incidentes de seguridad ocurridos que ha tenido impacto legal.
• Porcentaje de incidentes que son debidos a la seguridad, en relación al total
de incidentes.
• Número medio de incidentes de seguridad por servidor.
• Coste de la inseguridad, debido a tiempos de parada del negocio a conse-

cuencia de incidentes de seguridad, lucro cesante del negocio, etc.
• Coste de la seguridad, porcentaje del presupuestario dedicado a seguridad en
relación al presupuesto total de TI.
• Ratio de recursos humanos dedicados a la seguridad en relación al total de
personal de TI.
• Índice de rotación del personal en seguridad de la información.
• Porcentaje de ordenadores personales asegurados técnicamente.
• Porcentaje de no disponibilidad de servicios debido a incidentes de seguri-
dad de la información.
• Número y porcentaje de controles de seguridad revisados en el mes.
• Número de no conformidades relacionadas con la seguridad en auditorías y
controles internos.
• Número de mejoras sugeridas a los controles de seguridad.
En la figura 6.6.15 se muestra un resumen de los indicadores anteriormente men-

cionados, teniendo en cuenta que no son los únicos.
Figura 6.6.15. Métricas del proceso de seguridad de la información

Roles participantes en la gestión de seguridad

Como en el resto de los procesos, los roles intervinientes en la gestión de la seguri-
dad de la información se estructuran en dos roles; los roles propios del proceso y
los roles ajenos al proceso.
Entre los roles clave del proceso, a nivel interno, se encuentran los siguientes:
• La dirección de la empresa u organización, cuyo representante tiene la res-
ponsabilidad de revisar y aprobar el análisis de riesgos, declarar qué riesgos
no son aceptables por la organización, incluir en las revisiones del sistema
por la dirección el estudio del análisis de riesgos, aprobar el plan de gestión
del riesgo, conocer el grado de implantación del plan de gestión del riesgo,
incluir en las revisiones del sistema por la dirección un análisis del plan de
gestión del riesgo implantado en el período anterior.
• El gestor de seguridad de la información, responsable del funcionamiento de
todo el proceso y específicamente de:
– Realizar la evaluación de riesgos.
– Presentar a la dirección el nivel de riesgo soportado por la organización.
– Elaborar el plan de tratamiento de riesgos.
– Realizar el seguimiento del plan de tratamiento de riesgos.
– Informar a la dirección de la implantación de los planes.
– Analizar los resultados de la implantación de los controles y los planes.
• El comité de seguridad, como mecanismo asesor al responsable de seguridad

y medio para la participación de todas las áreas en los temas esenciales relati-
vos a la seguridad.
• El administrador de soporte del proceso de seguridad, que contribuye a que
las actividades del proceso funcionen, es responsable de coordinar y apoyar
la elaboración del análisis de riesgos, presentar al responsable de seguridad el
nivel de riesgo soportado por la organización, coordinar y apoyar la elabora-
ción del plan de tratamiento de riesgos, coordinar y realizar el seguimiento
del plan de gestión del riesgo, informar al responsable de seguridad de la
implantación del plan de gestión del riesgo y coordinar y apoyar la implanta-
ción del plan de gestión del riesgo.
Este proceso se apoya también en otros roles relevantes para el mismo y que son
ajenos al proceso:
• El responsable de seguridad general de la organización, a quién habrá que

informar de los temas específicos de seguridad de la información.
cumplan los niveles pactados, aporta la relación con la dirección de la
empresa y las principales directrices para la seguridad de la información, pro-
porcionan los presupuestos, presenta al comité de dirección la evaluación de
riesgos elaborada, el plan de tratamiento de riesgos y la declaración de ries-
gos, con el fin de que sean aprobados convenientemente y se otorgue el res-
paldo adecuado a las medidas técnicas y organizativas necesarias para miti-
gar el riesgo.
• El responsable de la gestión de la continuidad de los servicios de TI, pues los
dos procesos tienen muchos puntos en común, especialmente en la evalua-
ción de riesgos, cada uno desde la perspectiva de su proceso.
• El gestor de las relaciones con el negocio. Para llevar la relación con las áreas
cliente de una forma centralizada, la gestión de la seguridad tomará los
requisitos del negocio y presentará los informes. El gestor de nivel de servi-
cio velará por el cumplimiento de los requisitos de seguridad y por atender
las expectativas de los clientes respecto a esta materia.
• El propietario del modelo de gestión (SGSTI y también del SGSI), que
actúa como propietario de este proceso (process owner), define las actividades
del proceso y se encarga de la mejora continua del mismo. Este propietario
también debería desempeñar las funciones de propietario del modelo de gestión
de la seguridad SGSI.
En la figura 6.6.16 se muestran los roles principales del proceso.
Resumen
El incremento continuo de las amenazas hace que la seguridad de la información
sea cada vez un aspecto más crítico en las empresas. La red Internet es el cauce por
el que llegan la mayoría de ellas. Si las amenazas han aumentado por esta vía, las
vulnerabilidades también: la conectividad desde cualquier lugar, la proliferación de
aparatos tecnológicos en el mercado de consumo en la empresa, la gran capacidad
de los dispositivos de bolsillo en la empresa, etc.
La seguridad se ha convertido en los cimientos sobre los que se sustenta la infor-
mación de la empresa, cimientos que hay que cuidar continuamente para que no
pierdan su solidez.
Roles del proceso
Responsable de la
Dirección
SGSTI
SGSI
Responsable
de seguridad
Propietario del modelo

(SGSTI y SGSI)
Comité de seguridad
Administrador y
soporte del proceso
Áreas técnicas de seguridad
Gestor continuidad TI
Figura 6.6.16. Roles que intervienen en el proceso de gestión

de la seguridad de la información
El marco normativo internacional pone foco en la gestión de la seguridad apor-

tando un conjunto de requisitos y buenas prácticas que ayudan a las empresas a
enfocar su implantación. Resulta esencial utilizar la normativa existente. La Norma
ISO/IEC 27001 aporta un conjunto de actividades y buenos controles para mejo-
rar la seguridad, mientras que ISO/IEC 20000 integra la gestión de la seguridad
con el resto de los procesos de gestión de los servicios de TI.
La implementación de la gestión de la seguridad de la información se articula en
torno a un proceso específico, que permite controlar la seguridad en la empresa y
sus riesgos asociados. Este proceso gestiona el mantenimiento de unos niveles de
seguridad adecuados, tanto en la prestación de los servicios de TI, como para el
control de los activos de información de la organización.
Los principales elementos de la gestión de la seguridad son:

• La política de seguridad.
• El responsable de seguridad.
• El comité de seguridad.
• La evaluación de riesgos.
• Los objetivos de control y los controles.
• La declaración de riesgos o declaración de aplicabilidad.
• El plan de tratamiento de riesgos.
• La gestión de incidentes de seguridad.
• Los registros de seguridad.
Beneficios
Entre los beneficios más relevantes que proporciona la gestión de la seguridad de la
información destacan los siguientes.
• Protege y aumenta la robustez y seguridad de los sistemas de información,
realizando un tratamiento adecuado de los riesgos, reduciendo el riesgo de
sustracción o pérdida de información esencial.
• Proporciona confianza a todas las partes. A la dirección porque sus activos
están mejor protegidos, al mercado porque son más robustos los sistemas, y
al departamento de TI porque le permite cumplir las exigencias de la dirección.
• Asegura que los incidentes de seguridad de la información son correcta-
mente gestionados, reduciendo su impacto en el negocio.
• Establece auditorías de seguridad con regularidad, que comprueban la ade-
cuación de las medidas de seguridad implantadas.
• Aporta información a la dirección sobre el estado de seguridad de la empresa
u organización, de cara a adoptar las medidas que se consideren oportunas.
• Fortalecimiento de la imagen ante el mercado y confianza de los clientes en
una organización que apuesta por la seguridad de la información.
• Ahorro de costes por evitar incidentes de seguridad, en primas de seguros,
por sanciones derivadas de incumplimientos legales, etc.
• ¿Cómo se realiza la gestión de la seguridad de la información en su
empresa?
• ¿Está la dirección de su empresa implicada en la gestión de la seguri-
dad de la información?
• ¿La gestión de la seguridad se trata en su organización como un
ámbito independiente o de forma integrada con los otros procesos de
gestión de los servicios de TI?
3 Le recordamos que puede compartir sus experiencias y debatir las respuestas con los autores y
7 Procesos de
Capítulo 7
relaciones
7.1. Generalidades
7.2. Gestión de las relaciones con el negocio
7.3. Gestión de suministradores


7. Procesos de relaciones 451
Con el fin de garantizar que el proveedor de TI trabaje alineado con las necesida-
des de la empresa, las Normas ISO/IEC 20000 establecen los procesos de relacio-
nes. Regulan las relaciones en los dos extremos de la cadena de provisión de TI. Por
una parte se definen las relaciones con el negocio y, por otra, las relaciones con los
suministradores.
La misión de la gestión de las relaciones con el negocio es garantizar que se crean,
mantienen y mejoran continuamente los servicios de TI que necesita la empresa. Al
igual que en ITIL, en ISO/IEC 20000 el negocio está representado por la figura
del cliente. Se entiende como “cliente” a la persona, área o áreas de la empresa que
especifican los servicios de TI que necesitan y acuerdan los SLA. Para ello, el pro-
ceso de gestión de las relaciones con el negocio servirá de interlocución único entre
el cliente y la organización de TI, para la identificación de necesidades y la provi-
sión de los servicios. Cuenta con la colaboración continua de la gestión de nivel de
servicio y de otros procesos, para tratar de encontrar el balance correcto entre la
demanda del cliente, la provisión de los servicios, el coste de los mismos y la satis-
facción del cliente.
Por otra parte, hay que tener presente que los servicios que TI ofrece se construyen
formando un “puzzle” de piezas tecnológicas, adecuadamente integradas y gestio-
nadas. Para mantener en marcha este puzzle de tecnologías, la organización de TI
necesita suministradores diversos: de hardware, de productos software, integrado-
res, consultores, empresas de servicios, etc. La gestión adecuada de dichos suminis-
tradores es también esencial para poder garantizar los niveles de servicio requeridos.
En este capítulo se presentan las mejores prácticas para el éxito en la gestión de las
fronteras de la organización de TI: con el negocio y con los suministradores.
7. Procesos de relaciones
7.1. Generalidades 453
7.1. Generalidades
Figura 7.1.1. Los procesos de relación en ISO/IEC 20000
Con frecuencia se oye hablar de la importancia de una gestión adecuada de las rela-
ciones, especialmente en el ámbito de TI. Pero, ¿en qué consiste la gestión de una
relación?, aunque esta disciplina parece atractiva, no es fácil concretar su contenido
y conseguir con ello un aporte real a la mejora del servicio de TI.
En general, se puede decir que la gestión de una relación es aquella disciplina que
establece el método para que la interacción entre dos partes sea eficaz, ayuda a que
transcurra con las mínimas fricciones y contribuye a que sea duradera (véase la
figura 7.1.1). Los mecanismos habituales que permiten regular y organizar una
relación compleja son los siguientes:
• El establecimiento de los objetivos principales que se quieren conseguir con
la relación.
• La definición de los diversos interlocutores por cada parte, los perfiles perso-
nales y las habilidades necesarias.
• La utilización de un marco, reglas y lenguaje común aceptado por ambas
partes.
• Definición y regulación de los momentos de interacción, estableciendo su

periodicidad, los medios, los mecanismos y los documentos que recojan los
acuerdos. Todo ello, mediante comités, grupos de trabajo, traspaso de peti-
ciones, integración de herramientas, etc.
• El establecimiento de los mecanismos de seguimiento, midiendo la eficacia y
la satisfacción con la relación para poder mejorarla.
• El establecimiento de los procedimientos y los mecanismos de apoyo a una
relación formalizada: convocatorias, actas, peticiones, informes, métricas,
reclamaciones, cobros, etc.
Los principales actores en los procesos de relación son los clientes de los servi-
cios (tanto internos de otras áreas de la empresa, como clientes comerciales rea-
les), el proveedor del servicio de TI (organización de TI o área de TI a la que
se esté aplicando estas normas) y los suministradores (que proporcionan bienes
o servicios a la organización de TI, que pueden ser internos de la empresa o
externos).
UNE-ISO/IEC 20000-1
Los procesos de relación describen los aspectos relacionados con la gestión de

suministradores y con la gestión de las relaciones con el negocio.
UNE-ISO/IEC 20000-2
Esta norma se dirige hacia el rol de un de servicio o de soporte interno que son
proveedor del servicio, el cual cumple a menudo designados como acuerdos
un papel entre los suministradores, que de nivel operacional.
proporcionan bienes o servicios a dicho
El proveedor del servicio juega un papel
proveedor del servicio, y los clientes, que
dentro de la cadena de suministro, en la
reciben los servicios.
cual cada eslabón debería añadir valor,
Tanto los suministradores, como los de forma que el proveedor del servicio
clientes pueden ser internos y externos que recibe bienes o servicios proceden-
a la organización del proveedor del tes del suministrador y entrega un servi-
servicio. cio mejorado al cliente.
Las relaciones externas se formalizarán A modo de aclaración, dentro de esta
mediante contratos. Las relaciones inter- sección el término proveedor del servicio
nas se formalizarán mediante acuerdos se utiliza siempre para describir la orga-
7.1. Generalidades 455
nización a la que se dirige este docu- b) entienden las capacidades y limi-

mento, independientemente del papel, o taciones;
sentido en la cadena, que tiene en el c) entienden las responsabilidades y
proceso que se describe. las obligaciones.
En la práctica, las relaciones raramente Estos procesos también deberían asegu-
son así de simples, sino que implican rar que los niveles de satisfacción del
múltiples participantes, asumiendo cliente son apropiados y que se comu-
papeles, tanto como suministradores, nican y entienden las necesidades futu-
como clientes y con conexiones de ras del negocio.
negocio entre muchos de ellos de
forma directa o bien mediante el prove- El alcance, los roles y las responsabilida-
edor del servicio. des de las relaciones con el negocio y
las relaciones con los suministradores
Los procesos de relación deberían ase- deberían definirse y acordarse. Esto
gurar que todas las partes: debería incluir la identificación de todos
a) entienden y satisfacen las necesi- los grupos de interés, los contactos y los
dades del negocio; medios y frecuencia de la comunicación.
Si se echa una mirada a ITIL v2, se aprecia que no establece ningún proceso espe-
cífico que describa la relación con los suministradores, aunque hace mucho hinca-
pié en que los contratos con suministradores (contratos de soporte, Underpinning
Contracts o UC) respalden los compromisos del nivel de servicio que TI asume con
sus clientes. En cambio, en ITIL v3 el libro Diseño del Servicio define específica-
mente un proceso de gestión de suministradores.
En el marco para el gobierno y auditoría de TI (COBIT) de estos temas se encuen-
tran referencias, indicadores y controles centrados principalmente en el control de
las adquisiciones y el gobierno de TI. No trata específicamente las relaciones con el
negocio ni las relaciones con los suministradores bajo el concepto de proceso.
En el ámbito del desarrollo de software, las relaciones tanto con el cliente como con
los suministradores de desarrollo, están bastante detalladas en el modelo CMMI. Asi-
mismo, la universidad Carnegie Mellon también ha desarrollado el marco eSCM-SP
(eSourcing Capability Model for Service Providers) formado por 84 prácticas específicas
para la gestión de suministradores y el ciclo de vida del sourcing en TI.
Además, existen otros marcos de mejores prácticas en los que se trata la mejora de
las relaciones con los suministradores, como por ejemplo, el modelo ISPL (Infor-
mation Services Procurement Library1), que es un compendio europeo de mejores
1
Véase http://projekte.fast.de/ISPL/.
prácticas para la provisión y prestación de proyectos y servicios TI. ISPL fue publi-
cado en 1999 por un consorcio de 5 organizaciones europeas dentro del programa
SPRITE-S2 de la Comisión Europea y se basó en la experiencia de más de 200 pro-
cesos de compra reales en TI. Trata la definición de una estrategia de aprovisiona-
miento de servicios (sourcing), así como las etapas posteriores: peticiones de oferta,
establecimiento del contrato, planificación de la provisión y seguimiento de la eje-
cución. ISPL hoy está en desuso, por lo que la llegada del proceso en ITIL v3 es
bien acogida por el mercado.
Otros modelos sectoriales también tratan el entorno de la gestión de suministrado-
res, como es el caso del modelo eTOM para el sector de las telecomunicaciones,
que contempla procesos como por ejemplo, la gestión de partners/suministradores
o la gestión de la cadena de suministro.
7.2. Gestión de las relaciones con el negocio 457
7.2. Gestión de las relaciones con el negocio
Figura 7.2.1. Actividades del proceso de gestión de las relaciones con el negocio
Las empresas e instituciones tienen cada vez una mayor dependencia de las tecnolo-
gías de la información. Los departamentos de TI, y las actividades que desarrollan,
han sido vistos tradicionalmente como una carga y un coste para el negocio, infrauti-
lizándose el potencial de la tecnología para ponerse en primera línea, aportando ideas
y abriendo nuevas oportunidades para la empresa. Para que las tecnologías de la
información estén alineadas con las necesidades de la empresa, es necesario instru-
mentar una vía de comunicación permanente, regulada y eficaz entre TI y el negocio.
La gestión de las relaciones con el negocio asegura que la comunicación entre TI y
sus clientes sea clara y fluida (véase la figura 7.2.1). Se entiende como “cliente” a
las áreas internas de la empresa o a las unidades externas que especifican y contra-
tan los servicios de TI, diferenciándolo así de la figura del “usuario” que es la per-
sona que utiliza los servicios. Igual que el centro de atención al usuario (service desk)
es el punto único de contacto entre TI y la comunidad de usuarios, el proceso de
gestión de las relaciones con el negocio se convierte en canal único de la comunica-
ción reglada entre TI y el negocio.
Este proceso se preocupa de dar una respuesta adecuada a las demandas del cliente,
actuando de interfaz entre el negocio y las áreas de TI. Vela por la satisfacción del
cliente atendiendo sus reclamaciones y revisando periódicamente los acuerdos o

contratos establecidos.
Gran parte de las relaciones con el negocio se centralizan en una figura denomi-
nada habitualmente gestor del cliente. Con cierta frecuencia, se encuentra polari-
zada únicamente hacia los aspectos relacionados con el desarrollo de las aplicacio-
nes, descuidando todo lo relativo al seguimiento de los servicios en explotación. El
gestor del cliente debe tratar con el negocio dos aspectos: la provisión de la funcio-
nalidad requerida en forma de servicios (desarrollo) y el seguimiento de los servi-
cios ya operativos en explotación regular (producción).
La gestión de las relaciones con el negocio aporta una sistemática de trabajo que
facilita y hace más eficaz la relación. Ayuda a que TI ponga el foco en la provisión
de los servicios que realmente necesita la empresa.
El proceso de gestión de las relaciones con el negocio saca a TI de su ensimisma-
miento tecnológico para trabajar directamente en lo que necesita el negocio.
Refuerza y formaliza los lazos entre TI y sus clientes. Los servicios prestados se
revisan y contrastan con los clientes, se mide su satisfacción y se impulsan acciones
de mejora. En la figura 7.2.2 se presenta un esquema introductorio al proceso.
Proceso de gestión de las Qué aporta:

relaciones con el negocio • El objetivo de TI es la satisfacción
del cliente.
Definición: • Saca a TI de su mundo tecnológico.

• Fuerza a TI a trabajar para lo que
Proceso que regula las relaciones
necesita el negocio.
entre el departamento de TI y sus
áreas clientes. • Las relaciones con las áreas cliente se
gestionan con mayor profesionalidad.
• Los servicios prestados se revisan de
Objetivo: forma regular con los clientes de TI.
Establecer y mantener una buena • Se formalizan las reclamaciones.
relación entre el proveedor del
• Se mide la satisfacción del cliente.
servicio y el cliente, basándose en
el entendimiento del cliente y de • Se impulsan acciones de mejora del
los fundamentos de su negocio. servicio.
Figura 7.2.2. Introducción al proceso de gestión de las relaciones

con el negocio
El objetivo de la gestión de las relaciones con el negocio es establecer y mantener

unas buenas relaciones entre los clientes y TI mediante el entendimiento entre
ambos. Este entendimiento de las necesidades del negocio se debe traducir en la
prestación de servicios cumpliendo los niveles de servicio acordados y siguiendo e
informando acerca del rendimiento del servicio.
Para ello, el proceso de gestión de las relaciones con el negocio servirá de interlocu-
ción única entre el cliente y la organización de TI. Con la colaboración continua de
la gestión de nivel de servicio, tratará de encontrar el balance correcto entre la
demanda del cliente, la provisión del servicio, el coste y la satisfacción del cliente.
La gestión de las relaciones con el negocio constituye el único punto de contacto
entre el negocio o cliente y la organización de TI involucrada en la prestación de
los servicios. En la figura 7.2.3 se muestra el papel de interlocutor con las áreas
cliente de este proceso.
Figura 7.2.3. El proceso de relaciones con el negocio enmarcado

entre el negocio y el resto de la organización de TI
Para el desarrollo con éxito de la misión de este proceso es necesario que el perso-
nal involucrado en él, por parte de TI, conozca a fondo la naturaleza del propio
negocio. Pero también es imprescindible que estos profesionales conozcan perfec-
tamente a TI y sus capacidades, para saber qué puede ofrecer y en qué condiciones.
El espíritu de servicio al cliente es otro de los valores a buscar y potenciar entre los
participantes en este proceso, pero no es un requisito exclusivo del mismo, sino que
debe hacerse extensivo a toda la organización de TI. El rigor en la relación facili-
tará a TI alinearse con el negocio, tomando nota de las necesidades, formalizándo-
las en requisitos, redactando las actas de las mismas, realizando un seguimiento del
cliente e impulsando en el resto de TI al cumplimiento de las demandas. Así, estos
cuatro pilares en los que se sustenta este proceso se muestran en la figura 7.2.4.
Figura 7.2.4. Bases de la gestión de las relaciones con el negocio
Los mecanismos principales que facilitan el cumplimiento de los objetivos de este

proceso son: los acuerdos de nivel de servicio con el cliente (SLA) y el catálogo de
servicios de TI. Alrededor de estos dos elementos se desencadena la transformación
de la organización de TI, orientándose hacia el servicio y el cliente. En la figura 7.2.5
se muestra los principales componentes del proceso.
Los componentes principales que se emplean en el proceso de gestión de las rela-
ciones con el negocio son se detallan a continuación:
Acuerdo de nivel de servicio (SLA). Es un documento que recopila los compro-
misos acordados entre el cliente y el proveedor de servicios de TI relativos a las
condiciones de prestación o explotación del servicio requerido. El SLA lo gestiona
y define el proceso de gestión de nivel de servicio (véase el apartado 6.1).
Estrategia del negocio

Convertir
Estrategia de TI
necesidades en SLR
requisitos de servicio
Catálogo Necesidades
de servicios Servicios nuevos
o modificaciones
Cli
SLA: ent
e
Acuerdo PDCA
de nivel de SGSTI
servicio
TI
Informes Mejoras
del servicio
Reclamaciones Programa de mejora
al servicio del servicio (SIP)
Reuniones cliente-TI,
Encuestas y entrevistas
demanda y revisión
de satisfacción
del servicio
Figura 7.2.5. Componentes más destacados del proceso
El catálogo de servicios. Se utiliza para poner claridad en toda la relación con el

cliente, pues esta relación tiene como eje central la prestación de los servicios pre-
definidos en el catálogo. El catálogo lo gestiona y define el proceso de gestión de
nivel de servicio (véase el apartado 6.1).
Encuestas y entrevistas de satisfacción. Medio para conocer la valoración y per-
cepción subjetiva del cliente sobre los servicios de TI.
Estrategia del negocio y de TI. La estrategia y tendencias del negocio son un ele-
mento que utiliza las relaciones del negocio para identificar qué necesidades del
cliente están alineadas con esta estrategia y cuáles no. También la estrategia de evo-
lución de TI debe ser tenida en cuenta para enfocar las soluciones en la misma
dirección hacia la que camina TI.
Informes del servicio. El proceso trata con el cliente el tipo de informes del servicio
que se utilizarán para el seguimiento del cumplimiento de los niveles de servicio acor-
dados. Los informes los gestiona el proceso de generación de informes de servicio
(véase el apartado 6.2).
Las necesidades del cliente. El cliente manifiesta sus necesidades, alineadas o no

con la estrategia del negocio y encajadas o no con el catálogo. El proceso de ges-
tión de las relaciones con el negocio debe tratar con el cliente el encaje de las nece-
sidades concretas manifestadas con la estrategia y con el catálogo.
Nuevos servicios o modificaciones. Las necesidades del cliente no cubiertas por
servicios del catálogo dan origen a la creación de nuevos servicios o a las modifica-
ción de los existentes (véase el capítulo 5).
Propuestas de mejora. Realizadas por el proceso en función de los defectos
encontrados en la prestación de los servicios de TI. Se encaminan hacia el plan de
mejora de los servicios (SIP) o de la gestión del servicio (plan de mejora unifi-
cado).
Requisitos del servicio (SLR, Service Level Requirements). Documento que
estructura y formaliza las necesidades del cliente. Se escribe en el lenguaje y termi-
nología del propio cliente. Es un documento que elabora este proceso en colabora-
ción con el proceso de gestión de nivel de servicio.
Reuniones cliente-TI. Las reuniones entre ambas partes son el instrumento prin-
cipal del proceso de gestión de las relaciones con el negocio para gestionar la
demanda de soluciones por parte del cliente y la realización de un seguimiento con-
junto de la prestación de los servicios en curso.
Reclamaciones al servicio. Instrumento que formaliza el malestar y disconformi-
dad del cliente con el servicio o la atención prestada por TI. Es una pieza clave para
velar por la subsanación de los errores de TI y supone una oportunidad para me-
jorar la satisfacción del cliente.
Hay que tener en cuenta que el proceso de relación con el negocio colabora muy
estrechamente con el proceso de gestión de nivel de servicio. El primero gestio-
nando la relación de TI con el cliente y el segundo se responsabiliza del cumpli-
miento, por parte de la organización de TI, de los compromisos pactados con los
clientes.
En lo relativo al tratamiento que se hace a las relaciones con el negocio, en ITIL v2
y v3 se han distribuido las funciones entre la definición de la estrategia y la gestión
de nivel de servicio:
• En ITIL v2 las relaciones con el negocio se tratan en el libro Business Perspec-
tive, desde un punto de vista de la estrategia y también en el libro Soporte de
Servicio en el proceso de gestión de nivel de servicio.
• En ITIL v3, de forma similar, las relaciones con el negocio se tratan en el
proceso de gestión de la demanda (libro Estrategia del Servicio) y en el pro-
ceso de gestión de nivel de servicio (libro Diseño del Servicio).
En la figura 7.2.6 se muestra una comparativa entre el tratamiento de las relaciones

con el negocio en los diferentes marcos de gestión de TI.
Procesos en ISO/IEC 20000 Proceso en ITIL v3 Proceso en ITIL v2
Libro Estrategia del Servicio:

• Gestión relación con el negocio Libro Business Perspective:
• Generación de la estrategia
• Gestión de la demanda • Gestión relación con
el negocio
• Gestión del portfolio de servicios
Libro Provisión de Servicio:
• Gestión • Generación Libro Diseño del Servicio:
de nivel de de informes • Gestión de nivel de
• Gestión del catálogo de servicios servicio
servicio del servicio
Figura 7.2.6. Tratamiento de las relaciones con el negocio o cliente

en los diferentes marcos de gestión de TI

El proceso de gestión de las relaciones con el negocio se encarga del diálogo con el
cliente para atender sus necesidades, utilizando la oferta estándar de TI definida en
el catálogo de servicios. El gestor o los gestores de clientes deben escuchar al cliente
y tomar nota de sus necesidades. Si éstas encajasen con la oferta estándar de servi-
cios (catálogo) se realizará una petición de servicio, en caso contrario, se analizará
la posibilidad de proveerlas.
Por lo tanto, el proceso es el desencadenante del conjunto de actividades para la
satisfacción de las demandas del cliente, pero también el punto final de esta cadena
de provisión, para terminar comprobando con el cliente los resultados. Las entra-
das, actividades y salidas del proceso se muestran en la figura 7.2.7.
Como ya se ha señalado anteriormente, las entradas que activan el proceso son las
solicitudes expresas del cliente de nuevas necesidades, de información, las peticio-
nes o acuerdos obtenidos en las reuniones periódicas de seguimiento entre TI y el
cliente, y las reclamaciones o quejas comunicadas por el cliente a TI. Las entradas
de soporte secundarias utilizadas para el desempeño del proceso son la estrategia
del negocio, que aporta información sobre la evolución futura del mismo; la estra-
tegia de TI, que permite proponer soluciones alienadas con el resto de la organiza-
ción; el catálogo de servicios, en el que se refleja el ámbito de trabajo de TI; los
SLA existentes; el plan de mejora del servicio; los informes del servicio; etc.
En cuanto a la actividad realizada por este proceso, es muy similar a una función
comercial, realizando actividades propias o participando en su rol de canal de
Desencadenantes 3 Identificación de los clientes Salidas principales:

del proceso: 3 Seguimiento “comercial” de los Ü Requisitos nuevos o
Ü Solicitudes del cliente. clientes y de los compromisos. evolución de servicios
Ü Reuniones periódicas de 3 Contrastar necesidades con el (SLR).
seguimiento del cliente. catálogo de servicios de TI. Ü SLA firmado.
Ü Reclamaciones de los 3 Definir los requisitos de nuevos Ü Informes seguimiento
clientes. servicios o evolución de los clientes.
existentes (SLR). Ü Resultados encuesta
3 Aprobación por gestión del satisfacción cliente.
Ü Estrategia del negocio. cambio. Ü Propuestas de mejora.
Ü Estrategia de TI. 3 Propuestas de servicio y de SLA.
Ü Catálogo de servicios. Salidas secundarias:
3 Negociación del SLA.
Ü SLA anteriores. Ü Informes resolución
3 Seguimiento de la provisión del
reclamaciones.
Ü Plan de mejora de la servicio.
gestión del servicio. Ü Actas de las reuniones.
3 Revisiones del servicio prestado.
Ü Informes del servicio. 3 Gestión de reclamaciones al
servicio.
3 Medición de la satisfacción del
cliente.
3 Generación de propuestas de
mejora, de los servicios al Plan
de mejora del servicio (SIP) y a
los otros procesos.
3 Supervisión funcionamiento
del proceso. Mejora del
propio proceso.
comunicación con el cliente para los otros procesos. Se conforma así como un
punto único de relación con las áreas cliente de TI. El proceso interviene en las pri-
meras etapas de la creación de servicios (véase el capítulo 5) y engrana con la ges-
tión de nivel de servicio, tanto para la creación como para la prestación de los mis-
mos (véase el apartado 6.1). Las principales actividades del proceso son:
• Identificación de los clientes. En la implementación de este proceso, una
de las primeras actividades es la identificación de las áreas cliente y conseguir
que estas designen a sus representantes legítimos y reconocidos interna-
mente. Con los clientes identificados se podrá determinar la carga de trabajo
necesaria y el inicio de la gestión de estas relaciones. Este aspecto está reco-

gido de forma expresa en ISO/IEC 20000-1:
UNE-ISO/IEC 20000-1
El proveedor del servicio debe identificar y documentar quienes son los actores prin-
cipales y los clientes de los servicios.
• Seguimiento “comercial” de los clientes y de los compromisos. Es una

función permanente, en la que la gestión de las relaciones con el negocio se
convierte en un punto de relación único de TI con el cliente.
• Contrastar las necesidades con el catálogo de servicios de TI. Las necesi-
dades del cliente pueden venir motivadas directamente por las necesidades
del negocio, o bien por otras causas, como por ejemplo, normas de obligado
cumplimiento, políticas de la organización, imperativos legales del sector,
etc. Las necesidades expresadas por el cliente se contrastan con la oferta de
servicios contenida en el catálogo de servicios. Si las necesidades encajan en
el catálogo, se activa el procedimiento previsto de provisión del servicio
determinado.
• Definir los requisitos de los nuevos servicios o evolución de los existen-
tes (SLR). Si el catálogo de servicios no es capaz de cubrir las necesidades
planteadas, se toman los requisitos del servicio (formalizados en el docu-
mento SLR) para analizar si se pueden cumplir por TI, mediante un nuevo
servicio o la evolución de uno existente. La intervención de la gestión de
nivel de servicio en este punto es fundamental para ayudar la identificación
de los nuevos servicios o mejora de los ya existentes. El gestor de relaciones
con el negocio debe realizar la toma de requisitos de forma estructurada,
empleando el lenguaje del cliente y evitando la terminología técnica.
• Propuestas de servicio y de SLA. Una vez determinadas las distintas opcio-
nes posibles para satisfacer los requisitos del cliente, teniendo en cuenta la
relación calidad-precio, se establece una propuesta de servicio que describe
la solución por parte de TI en términos de objetivos, alcance, funcionalidad,
estimación de plazos de disponibilidad, esfuerzo y costes asociados. Lo
lógico es que las propuestas de servicio se hayan previsto en la cartera de pro-
yectos anuales y se disponga de un presupuesto asignado. Si no es así, porque
la necesidad de negocio no se ha podido prever, se deberá encajar en la car-
tera de proyectos actual y en los presupuestos en curso, o bien planificarla
para más adelante.
La propuesta de servicio, además de la solución propuesta, debe recoger los

indicadores y métricas de gestión, así como los mecanismos necesarios para
la revisión del servicio, control, seguimiento y evaluación del cumplimiento
de los niveles de servicio acordados. Antes de proponer estos compromisos
es necesario verificar, a través de la gestión de nivel de servicio, que la orga-
nización de TI puede cumplirlos y que cuenta con los medios de monitoriza-
ción necesarios para obtener las métricas acordadas.
La propuesta de servicio proporciona la información necesaria para elaborar
un borrador de acuerdo de nivel de servicio (SLA) para revisar y negociar
con el cliente como respuesta a su demanda. El contenido de este documento
se muestra en la figura 7.2.8.
Primer borrador de SLA
• Descripción del servicio:
– Funcionalidad.
• Seguridad y continuidad.
• Estimación de plazos de provisión y entrega.
• Estimación de costes asociados.
• Indicadores y métricas de gestión.
• Mecanismos de control y seguimiento de los
niveles de servicio acordados.
Figura 7.2.8. Ejemplo de estructura para el primer borrador de SLA
A continuación, el proceso de gestión de nivel de servicio genera un docu-

mento que describe la relación entre la funcionalidad requerida por el cliente
y la solución tecnológica necesaria para implementarla. Este documento se
denomina hoja especificaciones del servicio (SS, Spec Sheet). Es un docu-
mento interno de TI y describe los requisitos técnicos que son necesarios
para la provisión y entrega del servicio.
Antes de someter la propuesta de servicio a su estudio, a efectos de aproba-

ción preliminar, el gestor del nivel de servicio debe cerciorarse de que TI
puede cumplir los compromisos, verificando los acuerdos de nivel operativo
(OLA) internos con el resto de áreas de la organización de TI involucradas
en la prestación del servicio y los contratos de soporte (UC) con los sumi-
nistradores de servicios externos necesarios.
• Aprobación por la gestión del cambio. La propuesta de servicio debe ser apro-
bada por el proceso de gestión del cambio, de tal forma que nadie en TI incor-
pore un nuevo servicio o se proponga evolucionar uno existente sin la aproba-
ción de este proceso, que garantiza la cohesión y estabilidad de los servicios.
También se acotan los márgenes entre los que deben oscilar los niveles de servicio
a negociar con el cliente y se encaja en la planificación general de los proyectos y
en la lista de cambios (FSC, Forward Schedule of Change, véase el apartado 9.2).
• Negociación y aprobación SLA. Autorizado por la gestión del cambio, el
gestor de relaciones con el negocio, inicia un ciclo de negociaciones y revi-
siones con el cliente sobre los términos y condiciones del servicio a prestar
por la organización de TI. En esta actividad se acuerdan los plazos y funcio-
nalidades para la creación (plan de proyecto) y las condiciones de prestación
(SLA para la explotación).
Una vez que el servicio es aprobado por el cliente y el SLA formalizado, se
ponen en marcha, bajo la supervisión de la gestión del nivel servicio y, con la
ayuda de la gestión del cambio, las actividades necesarias para la provisión
y entrega al cliente del servicio demandado. En el apartado 6.1 del capítulo 6
se detallan el resto de actividades.
• Seguimiento de la provisión del servicio. Durante todo el período en el
que se está desarrollando el servicio, la gestión de las relaciones con el nego-
cio mantiene informado al cliente y gestiona las reuniones de validación que
sean necesarias.
• Revisiones del servicio prestado. Una vez que el servicio se ha puesto en
explotación, este proceso mantiene reuniones con el cliente para informarle
y realizar un seguimiento de los niveles de servicio que se estén alcanzando.
• Gestión de reclamaciones al servicio. Es importante instrumentar un
mecanismo formal por el cual el cliente pueda manifestar su disconformidad
con algún aspecto de los servicios prestados o con el comportamiento de TI
(más adelante se trata este tema).
• Medición de la satisfacción del cliente. Al igual que en el mundo comer-
cial, se debe medir la satisfacción del cliente, mediante encuestas o entrevis-
tas (más adelante se trata también este tema).
• Generación de propuestas de mejora. La relación con el cliente, las recla-

maciones y las encuestas de satisfacción llevan al gestor de las relaciones con
el negocio a identificar acciones de mejora de los servicios (que comunicará
a la gestión de nivel de servicio) para su incorporación al SIP (programa de
mejora del servicio), y oportunidades de mejora de los otros procesos, que
comunicará al gestor correspondiente.
• Supervisión y mejora del propio proceso. Como en todos los procesos de
ISO/IEC 20000, cada proceso debe realizar su propia actividad de mejora
continua, en este caso identificando puntos que redunden en una mayor
satisfacción del cliente. Las mejoras identificadas se comunican al plan de
mejora de la gestión del servicio (véase el capítulo 4).
Los resultados o salidas principales del proceso de relaciones con el negocio son los
requisitos de servicio acordados con el cliente, los SLA firmados, los informes de
seguimiento entregados al cliente, los resultados de las encuestas de satisfacción al
cliente y las propuestas de mejora. Otras salidas del proceso son, por ejemplo, los
informes emitidos sobre cómo se han resuelto las reclamaciones, las actas de las
reuniones con el cliente, etc.
Interrelación entre relaciones con el negocio y gestión

Los ámbitos de actuación de la gestión de las relaciones con el negocio y de la ges-
tión de nivel de servicio son complementarios y perfectamente engranados para
posibilitar dos temas clave: el éxito en la identificación de las necesidades del cliente
y su prestación con los niveles pactados. La gestión de la relación con el negocio se
encarga de todo lo relativo a la relación entre TI y el cliente, se podría decir que
lleva las relaciones “comerciales” de TI.
En cambio, la gestión de nivel de servicio desempeña una función más centrada en
organizar los servicios, se responsabiliza de su provisión y controla que TI cumple
los compromisos pactados. Así, se encarga de identificar, catalogar y documentar
los servicios, describiendo claramente los elementos que los integran para comple-
tar el catálogo de servicios. También debe capturar el grado de colaboración entre
las distintas áreas de la organización de TI e identificar todos los actores involucra-
dos en la provisión del servicio. Colabora en la identificación de nuevos servicios y
lleva el programa de mejora de los servicios (SIP) ya existentes.
En la figura 7.2.9 se muestra el engranaje entre las actividades de estos dos proce-
sos en el ciclo de creación de un servicio (véase también el capítulo 5).
Figura 7.2.9. Distribución de actividades entre la gestión de nivel de servicio

y la gestión de las relaciones con el negocio en ISO/IEC 20000
Requisitos de servicio del cliente (SLR, Service Level

Requirements)
Como ya se ha indicado, es un documento que describe de forma detallada las
necesidades del cliente. La descripción se realiza en el lenguaje del cliente para faci-
litar su entendimiento y validación. Este documento contiene la información de la
funcionalidad que deberá proveer el servicio. Se debe formalizar con el cliente, pues
sobre esta base se ejecuta todo el proceso de creación.
En la confección del documento de SLR, es mejor crear un primer borrador a
grandes rasgos que sirva como punto de partida para el diálogo con el cliente, para
ir ganando progresivamente más detalle y profundidad. Hay que involucrar al
cliente en la tarea de reflejar en un documento sus necesidades. Hay que tener cui-
dado de no ir demasiado lejos y de no parecer que esté presentándole al cliente un
“hecho consumado”.
La definición de los requisitos puede resultar difícil, pues puede que el negocio no
sepa exactamente lo que quiere, por lo que pueden necesitar ayuda para compren-
der y definir sus necesidades. Hay que tener en cuenta que los requisitos expresa-
dos al inicio irán concretándose y diferirán de los que finalmente se acuerden. Si se
realiza facturación del servicio, es frecuente que las diferencias entre lo solicitado
inicialmente y lo acordado sea mayor. Pueden ser necesarias varias tandas de nego-
ciaciones antes de lograr el equilibrio entre lo que se busca y lo que económica-
mente se puede conseguir.
En la figura 7.2.10 se muestra un ejemplo de estructura para el SLR.
Requisitos de nivel de servicio SLR
• Acuerdo de nivel de servicio firmado.
• Datos de contacto del cliente.
• Fecha de solicitud.
• Descripción del servicio:
– Nombre del servicio.
– Descripción de las funcionalidades requeridas.
• Características del servicio:
– Fecha de inicio del servicio .
– Fecha de finalización/desconexión del servicio.
– Horario del servicio y soporte.
– Requerimientos de disponibilidad y fiabilidad.
– Requerimientos de seguridad y continuidad.
– Requerimientos de interfaces.
– Requerimientos de rendimiento (tiempos de respuesta).
– Requerimientos de explotación y operación.
• Diseño del nivel de servicio.
– Modificaciones en caso necesario a los acuerdos de nivel
de servicio existentes.
• Responsabilidad del diseño/departamentos involucrados:
– Nombre del departamento.
– Participación requerida.
– Responsables y datos de contacto.
• Planificación.
• Fecha requerida de disponibilidad.
Figura 7.2.10. Ejemplo de SLR

Revisiones del servicio prestado

Una vez puesto el servicio en explotación regular, se deben realizar reuniones de
revisión periódicas del servicio con el cliente, manteniéndose así un contacto per-
manente que genera un ciclo de relación que permitirá a TI conocer su desempeño
y ajustarlo a las necesidades del cliente.
A este respecto, existe un nuevo reparto de funciones entre relaciones con el nego-
cio y la gestión de nivel de servicio. La gestión de nivel de servicio monitoriza el
servicio para determinar la calidad, fiabilidad y disponibilidad del mismo, y genera
informes del nivel de servicio, de acuerdo al proceso de generación de informes
(véase el apartado 6.2). Las relaciones con el negocio presenta y analiza con el
cliente toda la información y los informes generados.
ISO/IEC 20000 establece unos requisitos mínimos para que la revisión del servicio
prestado se realice de una forma periódica y procedimentada.
UNE-ISO/IEC 20000-1
El proveedor del servicio y los clientes se deben reunir, al menos una vez al año,
para la revisión del servicio y para discutir cualquier cambio en el alcance del
mismo, en el SLA, en el contrato (si existe) o en las necesidades del negocio. Se
deben mantener reuniones a intervalos acordados para discutir el comportamiento y
las prestaciones, los cumplimientos, asuntos varios y planes de acción. Estas reunio-
nes se deben documentar.
A las reuniones puede invitarse a otros actores relacionados con el servicio.
Los cambios al contrato(s), si existen, y al SLA deben ser el resultado de las reunio-
nes mencionadas, cuando sea apropiado. Estos cambios deben estar sujetos al pro-
El proveedor del servicio debe permanecer al tanto de las necesidades del negocio y de
los principales cambios en el mismo para preparar una respuesta a dichas necesidades.
UNE-ISO/IEC 20000-2
El proveedor del servicio y los clientes previo, tratar las necesidades de nego-
deberían realizar revisiones del servicio, cio actuales y previstas y proponer cual-
al menos anualmente y antes y después quier cambio necesario en el alcance
de cambios importantes. La revisión del servicio y los SLA. Otros grupos de
debería considerar el comportamiento interés implicados como por ejemplo
subcontratistas, clientes, grupos de El proveedor del servicio debería planificar

usuarios u otros grupos representativos, y registrar todas las reuniones formales,
pueden ser invitados a participar en las registrar los problemas tratados y realizar
reuniones de revisión. el seguimiento de las acciones acordadas.
El proveedor del servicio y los clientes El proveedor del servicio debería esta-
deberían también acordar los procedi- blecer una relación con sus clientes de
mientos de revisión parcial para tratar el manera que éstos puedan estar al tanto
progreso, los logros y los problemas de las necesidades del negocio y de los
detectados. Estas reuniones deberían cambios principales para poder pre-
planificarse y ser notificadas a los grupos pararse para dar una respuesta a los
de interés para los que sea relevante. mismos.
Conviene destacar varios aspectos que se deben tener en cuenta en las revisiones
del servicio con los clientes, apuntados por estas normas, pues suponen un avance
a muchas de las prácticas actuales. Son las siguientes:
• El gestor de la relación debe reunirse de forma periódica con todas las áreas
cliente para revisar el servicio, los niveles de servicio prestados frente a los
requeridos en el SLA, el grado de satisfacción del cliente, etc. Se trata de eva-
luar la calidad del servicio desde el punto de vista del cliente.
• El mantenimiento de reuniones en los plazos acordados y, como mínimo,
una vez al año. Lo habitual es que las reuniones de revisión con los clientes
sean mensuales. En servicios críticos en períodos de inestabilidad las reunio-
nes pueden llegar a ser semanales.
• Las reuniones de revisión deberían estar procedimentadas, para que transcu-
rran de una forma eficiente y no se deje ningún tema sin tratar. De estas reu-
niones debe haber un acta formalizada y aprobada por todas las partes.
• A las reuniones con los clientes se puede invitar a otros actores, pues la rela-
ción con el cliente no es un coto cerrado. Ahora bien, la asistencia de diver-
sos miembros debe ser preparada para presentar entre todos una imagen de
TI coherente y alineada hacia los mismos objetivos. No hay nada más
penoso que una discusión interna de TI delante del cliente.
• Como consecuencia de estas reuniones, surgirán propuestas de cambio al
servicio o al SLA. Toda propuesta de cambio se gestionará con una petición
de cambio reglada (RFC) que pasará al control del proceso de gestión del
cambio.
• Este contacto permanente debe aprovecharse para que TI esté al tanto de
la situación y evolución del área de negocio, con el objetivo de facilitar la
anticipación de TI. Por ello, el gestor de las relaciones con el negocio debe-
ría concretar esta información obtenida en un informe, o un comunicado por
escrito, a la dirección de TI o al área de estrategia de TI, de los cambios de
tendencia junto con una predicción sobre las demandas futuras del área
de negocio hacia TI.
Es necesario establecer el “punto de inflexión” en el que se considera que un servicio

deja de ser útil para la organización. La gestión de las relaciones con el negocio debe
detectar los casos en los que la provisión de un servicio genera un coste superior al
valor que proporciona, analizar su retirada o proponer alternativas de evolución.
Como resultado de esta etapa, en la que se evalúan los niveles de los servicios prestados
realmente, se identifican y proponen las acciones oportunas para su mejora. La gestión
de relaciones con el negocio propone estas acciones de mejora al proceso de gestión de
nivel de servicio para que las incorpore al programa de mejora del servicio (SIP).
Reclamaciones del servicio

Debido a la propia naturaleza de los servicios de TI, complejos y con una interven-
ción humana intensiva, es normal que ocurran fallos. Los procesos de resolución
(gestión del incidente y gestión del problema) junto con el resto de los procesos
tratan de evitar, minimizar y resolver estos fallos. Pero los fallos ocurrirán y crearán
dificultades al negocio.
Las Normas ISO/IEC 20000 incorporan un apartado bastante innovador en las
prácticas de las organizaciones de TI, que es la gestión de las reclamaciones de los
clientes sobre los servicios. El tratamiento de las reclamaciones es una nueva
palanca que impulsará numerosas acciones de mejora de TI, subsanando carencias
y permitiendo que los servicios prestados estén más próximos a los clientes.
El tratamiento de las reclamaciones es una actividad asignada a la gestión de las
relaciones con el negocio.
UNE-ISO/IEC 20000-1
Debe existir un proceso de reclamaciones. La definición de la reclamación formal

sobre el servicio debe estar acordada con el cliente. Todas las reclamaciones forma-
les sobre el servicio son registradas por el proveedor del servicio, investigadas, con-
troladas emprendiendo acciones sobre ellas, informadas y formalmente cerradas.
Cuando una reclamación no sea resuelta mediante los canales normales, el cliente
debe disponer de un mecanismo de escalado.
UNE-ISO/IEC 20000-2
El proveedor del servicio y los clientes Las reclamaciones más relevantes se

deberían acordar un procedimiento for- deberían revisar periódicamente y ser
mal de reclamaciones que elimine cual- escaladas a la alta dirección si no se
quier ambigüedad sobre qué constituye resuelven dentro de los plazos acorda-
una reclamación y cómo se debería dos con los clientes.
gestionar. El proveedor del servicio
debería poner en marcha un proceso
analizar periódicamente las reclamacio-
para tomar las acciones adecuadas en
nes registradas para identificar tenden-
la resolución de los problemas.
cias y elaborar informes con este análi-
El proceso debería identificar a la persona sis para los clientes.
de contacto en el proveedor del servicio al
Los resultados de tal análisis se debe-
que dirigir las reclamaciones formales.
rían usar cuando sea apropiado para el
El proveedor del servicio debería regis- establecimiento de un plan de mejora
trar, investigar, tomar acciones, elaborar del servicio.
informes y cerrar formalmente todas las
reclamaciones de servicio.
Un cliente no se molesta en poner una reclamación si no está fuertemente discon-

forme con el servicio o el trato recibido. Por tanto, la gestión de la reclamación es
fundamental para conseguir mejorar la satisfacción del cliente.
La reclamación es el último instrumento que le queda al cliente para manifestar su
disconformidad. Las reclamaciones más graves, si no se resuelven, se deben escalar
a la alta dirección.
Para que las reclamaciones resulten un instrumento de mejora para TI, se debe esta-
blecer un procedimiento para su registro, seguimiento y resolución. Las reclama-
ciones deben ser analizadas, clasificadas y tratadas. Unas desencadenarán una
mejora sencilla en TI, en otras será suficiente con una explicación o disculpa al
cliente, pero habrá algunas que requieran un cambio más sustancial en el servicio o
en la organización de TI. El tratamiento de reclamaciones en ISO/IEC 20000 no
llega a tener la categoría de proceso principal, aunque se pide un procedimiento o
sistemática para su seguimiento y resolución. Las reclamaciones se registran, tienen
plazos de resolución, se investigan, se escalan, se inician acciones para su resolu-
ción, se informa sobre ellas y se cierran formalmente.
Las reclamaciones se deben dirigir a una persona de contacto en TI claramente
identificada, que conviene que sea distinta de los gestores que habitualmente se
relacionan con el cliente.
En la figura 7.2.11 se presenta un ejemplo del formato para la ficha de registro de

una reclamación.
Ficha de reclamación
Datos a rellenar por el cliente:

• Código reclamación.
• Estado de la reclamación.
• Persona que la realiza.
• Fecha alta.
• Servicios implicados.
• Título de la reclamación.
• Descripción o detalle de la reclamación.
• Valoración de la importancia por el cliente.
Datos a cumplimentar por TI en su resolución:

• Clasificación de la reclamación.
• Prioridad de la reclamación (similar a incidentes).
• Acuerdo del nivel de servicio asociado.
• Datos de contacto del cliente.
• Fecha de registro.
• Asignación.
• Resultados de la investigación.
• Conclusión y acciones emprendidas.
• Fecha de cierre prevista.
• Cierre de la reclamación.
• Comentarios del cliente al cierre.
• Fecha de cierre real.
• Etc.
Figura 7.2.11. Ejemplo de ficha de registro de reclamaciones

Medición de la satisfacción del cliente

La medición de la satisfacción del cliente es una práctica habitual en el mundo
comercial y también frecuente en las organizaciones de TI. La medición de la satis-
facción permite conocer de forma proactiva la percepción y la opinión sobre los
servicios prestados y la atención recibida.
La organización de TI mide la satisfacción en tres ámbitos:
• La satisfacción de las áreas clientes, realizada por este proceso.
• La satisfacción de los usuarios, realizada por el centro de servicio al usuario
(service desk), en el cierre de cada incidencia o de forma periódica, bajo las
directrices de este proceso.
• La encuesta de clima laboral interno en TI, realizado habitualmente en cola-
boración con recursos humanos (fuera del alcance de este proceso).
En las Normas ISO/IEC 20000 no queda clara la distinción del término cliente
(área cliente de TI que especifica los servicios) y de usuario (persona que utiliza los
servicios). Por lo que el tratamiento de la medición de la satisfacción del cliente en
estas normas se debe entender que corresponde a los dos ámbitos: al cliente y al
usuario.
UNE-ISO/IEC 20000-1
El proveedor del servicio debe tener una o varias personas asignadas como respon-
sable(s) de gestionar la satisfacción del cliente y todo el proceso de gestión de rela-
ciones con el negocio. Debe existir un proceso de medición periódica de la satisfac-
ción del cliente para obtener información y comentarios, y actuar en consecuencia.
Las acciones de mejora que se identifiquen durante este proceso se deben registrar y
utilizar como información de entrada para un plan de mejora del servicio.
UNE-ISO/IEC 20000-2
Se debería medir la satisfacción del de forma que los clientes puedan respon-
cliente para permitir al proveedor del ser- der fácilmente y sin que se requiera un
vicio comparar el desempeño con los excesivo tiempo para cumplimentar de
objetivos de satisfacción de clientes y con una manera adecuada dicha encuesta.
encuestas previas. El alcance y la comple- Se deberían investigar las variaciones
jidad de la encuesta se deberían concebir significativas en los niveles de satisfac-
ción para llegar a entender las razones deberían tratar con el cliente. Se debe-
de las mismas. ría acordar un plan de acción, utilizán-
Los análisis de tendencias u otras com- dolo como entrada para un plan de
paraciones solo deberían realizarse mejora del servicio sobre cuyo progreso
sobre preguntas comparables y entre se informe al cliente.
métodos de muestreo comparables. Las felicitaciones sobre el servicio se
Los resultados y conclusiones de las deberían documentar y dar a conocer al
encuestas de satisfacción del cliente se equipo que esté prestando el servicio.
Los medios habituales para la medición de la satisfacción son la encuesta y la entre-

vista guiada. En ocasiones se puede conocer la percepción de un grupo de clientes
o de usuarios seleccionados sobre un servicio mediante técnicas de análisis en
grupo como pueden ser los focus group.
En el proceso de relaciones con el negocio recae la responsabilidad de la medición
de la satisfacción del cliente (y de los usuarios). Se debe establecer un procedi-
miento periódico para la medición de la satisfacción. Las encuestas deben ser senci-
llas de cumplimentar. Los resultados deben analizarse e investigarse las desviacio-
nes que existan. Con los resultados de las encuestas se debe preparar un plan de
mejora a tratar con las áreas cliente. Las mejoras se incorporarán al programa
de mejora del servicio (SIP) o al plan unificado de mejora de los procesos, según
sea el tipo de mejora.
Es importante difundir entre el personal de TI las felicitaciones recibidas por el
servicio, de cara a subir la moral y reforzar las acciones positivas.
Relaciones con otros procesos

Si el centro de servicio al usuario (service desk) es el punto único de contacto con
los usuarios, el proceso de relaciones con el negocio hace de punto único de con-
tacto con las áreas cliente. Todo proceso o unidad de TI que necesite contactar con
los clientes lo hará a través de este proceso. De esta forma se centralizan las relacio-
nes y el cliente siempre trata todos sus asuntos con el mismo interlocutor de TI.
El proceso de gestión de relaciones con el negocio participa en la planificación e
implementación de servicios nuevos o de servicios modificados, en los proyectos y
procesos de desarrollo de software, en el seguimiento de los niveles de servicio, etc.
En la figura 7.2.12 se muestra la función de punto de contacto con el cliente, man-
tenida por este proceso, y la estrecha colaboración existente entre el gestor de rela-
ciones y el gestor de niveles de servicio.
Figura 7.2.12. La misión de punto de contacto único con el cliente de este proceso

Las métricas asociadas al proceso miden el desempeño de la relación entre TI y el
cliente para determinar cómo es de fluida, eficiente y satisfactoria. Por otra parte,
las métricas recogerán información sobre la satisfacción de los clientes y usuarios
con los servicios de TI. Los principales indicadores asociados al proceso son:
• Intensidad de la relación: número de reuniones con las áreas cliente, ratio de
número de reuniones por cliente al año, duración media de una reunión,
número medio de asistentes de TI y del negocio por reunión, número medio
de personal de TI ajeno al proceso que participa en las reuniones con el
cliente y número de actas de reunión remitidas en el plazo acordado.
• Eficacia de la relación: mediante el plazo medio necesario para cerrar un
SLA, el número medio de veces que es necesario reunirse para acordar
un SLA y el número de necesidades del cliente que no se han podido satis-
facer.
• Porcentaje de propuestas de SLA aceptadas por el cliente a la primera.

• Porcentaje de SLA con modificaciones relevantes en el año por petición
expresa del cliente.
• Porcentaje medio de satisfacción de los clientes con TI. Porcentaje medio de
satisfacción de los usuarios con TI. Aunque es una métrica claramente subje-
tiva, su valor es innegable para TI. Se miden mediante encuestas de satisfacción.
• Número total de reclamaciones al mes o al año. Número y porcentaje de
reclamaciones abiertas al final del mes, número anual de reclamaciones por
área cliente y tiempo medio en cerrar una reclamación.
• Número de total mejoras propuestas por este proceso. Del total de las mejo-
ras, porcentaje de ellas que han sido propuestas por este proceso.
• Número de mejoras generadas como consecuencia de la gestión de reclama-
ciones.
• Costes del proceso. Ratios de costes medio por actividad del proceso: coste
medio por reunión, coste medio en la definición de un SLA, coste medio de
resolución de una reclamación, etc.
En la figura 7.2.13 siguiente se muestra el resumen de los indicadores más relevan-

tes para este proceso.
Figura 7.2.13. Resumen de las métricas para este proceso

estratificadas por destinatario

Como en el resto de los procesos, los roles intervinientes se estructuran en los roles
propios del proceso y los roles ajenos al proceso (el gestor del nivel de servicio).
• El gestor de las relaciones con el negocio (gestor del proceso o process mana-
ger), que es el responsable máximo del proceso y del cumplimiento de los
objetivos del mismo. Se encarga del funcionamiento del proceso en detalle,
de subsanar las deficiencias, de resolver conflictos, etc.
• Los gestores del cliente, que desempeñan una función operativa de conocer
al cliente, reunirse con él, conocer en detalle su actividad y mantener el día a
día de la relación. El gestor de cliente trata en su relación tanto la creación
de servicios (mediante desarrollo o adquisición), como el seguimiento de la
prestación de los mismos (explotación y operación).
• Los administradores o personal de soporte al proceso, personal que contri-
buye en organizar la actividad, realizar encuestas de satisfacción, realizar
informes, apoyo a los gestores de cliente, etc.

• El responsable de la gestión del servicio (service manager), que vela por que
todos los servicios cumplan los niveles pactados.
• Los gestores de nivel de servicio (SLM, Service Level Managers), que siguen
el cumplimiento de los acuerdos de los servicios a su cargo.
• El responsable de informes, aportando los informes a entregar al cliente.
• Los jefes de proyecto, bajo el proceso de planificación e implementación de
nuevos servicios o de servicios modificados.
(process owner), define las actividades del proceso y se encarga de la mejora
continua del mismo. Todo ello, de una forma integrada con el modelo de
gestión del proveedor de TI incorporado en el SGSTI.
Los roles de mayor relevancia que participan en el proceso de gestión del cambio
se representan en la figura 7.2.14.
Entre las habilidades y aptitudes necesarias, tanto del responsable del proceso
de gestión de relaciones con el negocio como de los gestores de cliente, deben
destacar:
Roles del proceso
Responsable de la
Gestor de las relaciones
SGSTI
con el negocio
Gestor del cliente
Propietario del
modelo (SGSTI)
Administrador y soporte
del proceso de relaciones
con el negocio
Gestores del Gestor de informes

nivel de servicio del servicio Jefes de proyecto
Figura 7.2.14. Roles del proceso de gestión de las relaciones con el negocio
• Una buena comprensión de los servicios de la organización de TI y de los

factores que los influyan, a fin de entender cómo afectarán los requisitos del
cliente a la provisión del servicio.
• Un buen entendimiento del negocio del cliente.
• Excelentes capacidades comunicativas y de negociación.
• Conocimientos y experiencia en gestión de contratos y suministradores.
• La capacidad para interactuar satisfactoriamente con todos los niveles de la
organización del cliente
• Un conocimiento técnico razonable y la capacidad para traducir los comple-
jos requisitos y especificaciones técnicas en conceptos que resulten fáciles de
entender para el negocio, y viceversa.
• Innovación respecto a la calidad del servicio y los modos en que puede mejo-
rarse dentro de los límites de la organización.
• Saber escuchar y tener la capacidad de aplicar los conocimientos recién
aprendidos de una manera efectiva.
Resumen
La gestión de la relación con el negocio permite una mejor alineación continua de
TI-Negocio, facilita y formaliza la relación para asegurar que la actividad de TI se
enfoca a las necesidades de la empresa.
Establece una disciplina de comunicación que, con un conjunto de documentos,
permite mejorar la efectividad de la relación. Los principales medios de formaliza-
ción que aporta o utiliza este proceso son:
• El catálogo de servicios, que constituye la base para el diálogo.
• Las necesidades del cliente se registran en una hoja de requerimientos del
servicio (SLR).
• Se negocia la formalización de los compromisos mediante los acuerdos de
nivel de servicio (SLA).
• Se mantienen reuniones de seguimiento periódicas del servicio prestado.
• Las quejas del cliente se registran como reclamaciones.
• Se conoce la opinión del cliente y de los usuarios mediante encuestas y entre-
vistas.
Beneficios
La gestión de las relaciones con el negocio se asegura de que las actividades lleva-
das a cabo en la provisión de los servicios contribuyen a los objetivos de negocio
del cliente. Entre los beneficios obtenidos destacan:
• Se asegura que el objetivo de TI es la satisfacción del cliente y que ésta se
mide.
• Saca a TI de su mundo tecnológico para orientarse al negocio.
• Fuerza a TI a trabajar para lo que necesita el negocio.
• Las relaciones con las áreas cliente se gestionan con mayor profesionalidad.
• Los servicios prestados se revisan regularmente con los clientes de TI.

• Se formalizan las reclamaciones.
• Se impulsan acciones de mejora del servicio.
• ¿Cómo se desempeñan las relaciones entre TI y las áreas de negocio en
su organización?
• ¿Cómo se tratan las quejas de los clientes en su empresa?
• ¿Cuál es la frecuencia y contenido principal de las encuestas a las áreas
cliente en su organización?
1
7.3. Gestión de suministradores 485
7.3. Gestión de suministradores
Figura 7.3.1. Actividades del proceso de gestión de suministradores
Mantener operativos y actualizados los servicios de TI requiere ineludiblemente

la gestión adecuada de un conjunto de suministradores, que será más o menos
amplio dependiendo de las estrategias de consolidación seguidas a lo largo de la
historia de la organización. Conocer cómo las empresas líderes llevan a cabo con
éxito la gestión de la relación con estas empresas externas aportará un conjunto
esencial de prácticas imprescindibles, que garantizarán la consecución de los
objetivos de TI.
Las relaciones entre empresas contratantes y sus suministradores se han enfo-
cado tradicionalmente como relaciones jefe-subordinado. Pero las relaciones
entre empresas acaban siendo siempre relaciones entre personas con nombres y
apellidos. Entendiendo este escenario, quizá se pueda abordar con más sensatez
las relaciones entre la organización de TI y sus suministradores (véase la figura
7.3.1). Dado que en los extremos de esta relación hay siempre personas, se
necesita un marco de actuación, una misión, ilusión, confianza, estímulo y tam-
bién exigencia. Así, en un contexto que equilibre la inteligencia emocional con
una demanda de resultados extrema, es en donde se debe desarrollar la relación
con los suministradores.
Esta relación se desarrolla en un entorno económico de tremenda presión y compe-

tencia. Por ello, el ajuste de costes puede ser tremendamente intenso en algunas
contrataciones. Esto introduce una fuerte presión sobre toda la cadena de suminis-
tro, pero se debe ser capaz de conjugar el rigor y la exigencia con el factor emocio-
nal que alimenta las relaciones humanas.
Por otra parte, la actividad de la organización de TI se torna cada día más compleja
y su evolución más dinámica. Se demandan nuevas especializaciones técnicas, se
necesita capacidad de adaptación, crecimiento, decrecimiento o evolución. Estas
funciones, que inicialmente se realizaban completamente por el personal propio de
la empresa, presentaba la problemática de necesitar una constante de evolución en
los conocimientos, por lo que las empresas han necesitado recurrir paulatinamente
a servicios externos para aprovisionarse de las nuevas capacidades necesarias.
De esta forma, la situación ha ido avanzando hasta el punto en el que una gran
parte de la actividad de la organización de TI se realiza por manos externas.
Así, es raro encontrar una gran organización que tenga programadores propios,
gran parte del desarrollo de software se ha externalizado, ya sea en forma de contra-
tos llave en mano (normalmente en el caso de grandes evolutivos) o bajo el con-
cepto de software factories (normalmente para el caso de pequeños desarrollos o
mantenimiento correctivo), y buscando siempre las economías de escala y zonas
geográficas de bajo coste salarial (offshore y nearshore).
El ámbito de la producción o explotación de los servicios, tampoco es ajeno a las
corrientes de externalización, que se iniciaron con la incorporación de personal
ajeno en formato de prestación de servicios o “body shopping”. Ha ido evolucionado
hacia la externalización de las funciones técnicas en modo servicio o sourcing selec-
tivo. En el caso más extremo de externalización se presenta el outsourcing completo
de toda la producción, cuando la organización de TI únicamente realiza el control
de un suministrador que realiza íntegramente todas las actividades.
Por ello, en la situación actual de fuerte externalización de las actividades, la ges-
tión adecuada de los suministradores cobra una gran importancia, pues en muchos
casos, estos llevan más del 70% de la actividad del departamento de TI.
La gestión de suministradores, si bien no es un proceso nuevo ya que existía como
tal en ITIL v2 dentro del libro Business Perspective, sí es un proceso que cuenta
con poco arraigue en la cultura de los departamentos de TI. En la mayoría de las
ocasiones, su foco se reduce al conocido proceso de compras y contrataciones. Con
este precedente, la gestión de suministradores se suele iniciar con la centralización
de las compras de TI, que impone cierto rigor en el proceso de adquisición. Pero el
seguimiento del cumplimiento y desempeño del suministrador a lo largo de todo
el ciclo de prestación del servicio, se ha dejado tradicionalmente al albedrío y a la
capacidad de reacción del equipo técnico que recibe el servicio contratado. La rea-
parición de este proceso primero en ISO/IEC20000 y después en ITIL v3 (en el
libro de Diseño del Servicio) pone de manifiesto la importancia que tiene en la nor-
mativa y marcos de buenas prácticas. En el presente apartado se presenta una visión
integral de la gestión de suministradores, que se inicia con la definición de la estra-
tegia y concluye con el término de los servicios contratados. Esta visión va más allá
de los límites establecidos en ISO/IEC 20000 para el proceso.
La gestión de suministradores es toda actividad dirigida a que los servicios contra-
tados al suministrador se presten según la forma acordada, para obtener el benefi-
cio previsto de los contratos para la organización de TI. Por tanto, la gestión de
suministradores supervisa, guía y exige a los suministradores el cumplimiento de lo
pactado en el contrato. Y, por otra parte, también debe velar porque la propia orga-
nización de TI contratante haga todo lo posible para que el servicio se preste con la
fluidez deseada.
Recalcar la diferencia terminológica entre suministrador o empresa externa a la que
se contrata algún producto o servicio y el término “proveedor de TI” en ISO/IEC
20000, que se refiere a la propia organización de TI o al departamento interno de
informática.
En la figura 7.3.2 se presenta un esquema introductorio al proceso.
Proceso de gestión Qué aporta:

de suministradores • Asegura la ejecución de la estrategia
de sourcing en lo relativo a la
contratación externa.
Definición:
• Da rigor y transparencia a las
Proceso que gestiona todo el actividades de contratación
aprovisionamiento y la prestación de los de productos y servicios.
productos y servicios que TI necesita.
Abarca las áreas de desarrollo de • Implementa una sistemática para que
software, de producción, etc. la relación y gestión de los
suministradores se realice de forma
homogénea por todas las unidades.
Objetivo: • Implementa las mejores prácticas
Gestionar los suministradores para del mercado en la gestión de los
garantizar la provisión sin suministradores.
interrupciones de servicios de calidad. • Alinea los servicios contratados
con las necesidades de TI.
• Almacena el conocimiento sobre los
suministradores y su desempeño.
Figura 7.3.2. Introducción al proceso de gestión de suministradores

La gestión de suministradores se encarga de la ejecución de la estrategia de sourcing

en lo relativo al aprovisionamiento exterior de productos y servicios relacionados
con las TI. Es un proceso ejecutor de la estrategia y las políticas de la empresa, pero
no se encarga de definirlas. La estrategia de sourcing es una parte importante de la
estrategia general de las TI y se desarrolla en otro ámbito (en el caso de ITIL v3,
los aspectos relacionados con la estrategia de sourcing se desarrollan dentro del libro
Estrategia del Servicio). En esta estrategia se definen las funciones esenciales que se
deben retener (que se realizarán internamente por personal propio) y las actividades
o áreas a externalizar, conformando lo que se conoce como políticas de sourcing.
La gestión de suministradores gestiona todo tipo de contratación, bien sea de con-
sultoría, de desarrollo de software, de soporte, de equipamiento, etc. También pone
foco en la gestión de la prestación de servicios del suministrador posterior a la con-
tratación.
El correcto desempeño de estas actividades requiere desarrollar 4 disciplinas o pila-
res esenciales que se muestran en la figura 7.3.3.
Una de las disciplinas principales en la gestión de suministradores es la perseveran-
cia en la relación, manteniendo una continuidad en las exigencias, en el segui-
miento, y en el trato con terceros. La perseverancia convertirá el buen hacer en
Figura 7.3.3. Bases de la gestión de suministradores

rutina habitual en la prestación del servicio, de tal forma que las reuniones, infor-
mes, escalados, etc. fluyan con total normalidad sin necesitarse un esfuerzo especí-
fico para conseguirlos.
Junto a esta faceta, el rigor en la relación, manteniendo un trato formal y documen-
tado, permitirá dejar trazas y evidencias de todo lo acontecido a lo largo de la his-
toria de la relación con cada uno de los suministradores.
No hay que olvidar que la relación con el suministrador se desarrolla en un marco
contractual, en el que debe haber una cobertura legal para la prestación y la gestión
de los desacuerdos. El carácter contractual debe estar presente a lo largo de toda la
relación.
El cuarto aspecto importante es el relativo a la función de interlocutor entre la
organización de TI y los suministradores. Para tener éxito en la mediación es nece-
sario que se conozcan y se gestionen los mecanismos que se van utilizar para que
fluya la relación con los suministradores y asegurar así el cumplimiento de lo con-
tratado y la satisfacción mutua. Frecuentemente se ignora esta faceta de facilitador
interno con toda la organización de TI para alcanzar los objetivos esperados en las
contrataciones, pero se debe velar por que todo el mundo cumpla con su parte. En
ocasiones, es el propio personal de la organización contratante quien dificulta o
ralentiza la prestación del servicio. Otras veces, son las deficientes interfaces entre
las herramientas las que dificultan el flujo de intercambio de información, de peti-
ciones o de trabajos.
En la gestión de suministradores, normalmente los problemas suelen surgir en las
fronteras e interfaces. En las fronteras en cuanto a la determinación de los límites
de lo contratado, entrando en discusiones sobre si una actividad está contratada o
no. En las interfaces por la necesidad de integración de los sistemas, organizacio-
nes, culturas, procesos y formas de hacer entre la organización TI contratante y las
diversas organizaciones de prestación de servicios de los suministradores.
De forma general, aunque no plenamente coincidente con las normas y estándares
de referencia, como se verá más adelante, el alcance de este dominio (gestión de
suministradores) debería comprender desde la definición de la estrategia de sour-
cing (realizada en el ámbito de la definición de la estrategia general de TI), pasando
por la selección y contratación, para seguir con la prestación o recepción de los ser-
vicios, hasta concluir con la etapa de finalización de los mismos.
De esta forma, y tomando como referencia el proceso similar definido en ITIL (en
su versión 2 dentro del libro Business Perspective, y en su versión 3 dentro del libro
Diseño del Servicio), en este capítulo se desarrolla un enfoque propio en el que,
cubriéndose también las actividades de establecimiento de la estrategia de sourcing
y de finalización o terminación del suministro, las actividades se agrupan en dos
grandes ciclos centrales: el ciclo de selección y contratación, y el ciclo de prestación.

Son dos ciclos en continuo movimiento en el que el primero se encarga de todas las
actividades a realizar en la fase de adquisición o compra (que se inicia con la necesi-
dad identificada y finaliza con el contrato adjudicado), mientras que el segundo
ciclo, el de prestación, controla la recepción de los productos o servicios contratados
(se inicia después de la adjudicación y finaliza con la expiración del contrato).
Como se ha indicado estos dos ciclos principales se complementan con una etapa
previa de implementación de la política de gestión de suministradores y otra de
finalización que gestiona adecuadamente la terminación de los servicios. En para-
lelo a todas las actividades se desarrolla la mejora continua del proceso.
Así, el proceso se presenta agrupado en los siguientes bloques.
• Etapa de planificación e implementación del proceso y de la política de sumi-
nistradores.
• Ciclo de selección y contratación de productos y servicios.
• Ciclo de prestación de los servicios contratados.
• Etapa de renovación o finalización de los servicios.
• La mejora continua del proceso.
El alcance dado al proceso en los diferentes estándares tiene sus diferencias. En

ITIL v3 la estrategia de sourcing se trata como parte de general de la estrategia de
TI (libro Estrategia del Servicio). En la figura 7.3.4 se muestra el esquema utilizado
en ITIL v3 para este proceso, identificándose los dos grandes ciclos propuestos en
este libro.
Por otra parte, la Universidad Carnegie Mellon, el otro gran actor en los marcos de
trabajo para la gestión de las TI, ha desarrollado un modelo de madurez para la
gestión de las externalizaciones y del outsourcing en dos versiones: una para las
organizaciones contratantes de servicios, denominadas “clientes” (eSCM-CL,
eSourcing Capability Model for Client Organizations) y otra para organizaciones
suministradoras de servicios, denominadas “proveedoras” (eSCM-SP, eSourcing
Capability Model for Service Providers). En la figura 7.3.5 se muestra un esquema del
primer modelo, constituido por 95 mejores prácticas.
En ISO/IEC 20000, los requisitos definidos para el proceso de gestión de suminis-
tradores no contemplan ni la estrategia de sourcing ni la selección de suministrado-
res. No obstante, en este libro sí se incluyen ambos aspectos porque la gestión de
suministradores es crítica en los resultados globales de la organización de TI. En la
figura 7.3.6 se muestra el alcance del proceso en el presente libro comparado con
los diversos alcances establecidos en ITIL v3 y en ISO/IEC 20000.
Figura 7.3.4. El proceso de gestión de suministradores en ITIL v3
Fases del ciclo de vida del outsourcing desde la perspectiva de organizaciones contratantes
Análisis Inicio Prestación Terminación

• Análisis oportunidades • Planificación de • Gestión del servicio • Finalización del
externalización la externalización externalizado servicio
• Estrategia de • Evaluación de
externalización suministradores
• Acuerdos (contratos)
• Transferencia
del servicio
Áreas permanentes de capacidad
• Gestión estratégica del sourcing • Gestión del valor • Gestión de los

• Gestión de la gobernabilidad • Gestión del cambio recursos humanos
• Gestión de las relaciones organizacional • Gestión del conocimiento
Fuente: CMMI y ASENTTI.
Figura 7.3.5. Esquema del modelo de gestión de outsourcing del modelo eSCM-CL
Figura 7.3.6. Diversos alcances del proceso de gestión de suministradores
En las Normas ISO/IEC 20000 la responsabilidad de demostrar el cumplimiento

de estos procesos de gestión de suministradores recae en el área de TI, denominada
proveedor del servicio. Hay que tener en cuenta que pueden existir relaciones en
cascada, encadenándose contratos de varios suministradores para el servicio final
de TI, como se muestra en el ejemplo de la figura 7.3.7.
Suministrador 1
Proveedor de TI
Negocio Suministrador 2
(área TI)
Suministrador 4
Suministrador 3
subcontratado
Figura 7.3.7. Ejemplo de relaciones entre el proveedor del servicio

y múltiples suministradores
Los mecanismos principales utilizados en el proceso de gestión de suministradores

para alcanzar sus objetivos, agrupados en función de cada una de las etapas, se
muestran en la figura 7.3.8.
Estrategia Selección y Renovación

Prestación
de sourcing contratación o finalización
• Estrategia de • Necesidad de TI • Contrato adjudicado, • Requisitos de

externalización • RFI con sus niveles de terminación
• Perfil de actividades a servicio • Preparación para la
• Caso de negocio
externalizar • Entrega del producto terminación
• RFP (SOR) o prestación del
• Políticas de • Renovación y
contratación • Hoja de compra servicio transición
• Objetivos de nivel • Asiento en el ERP de • Mecanismos de
de servicio a cumplir la compra relación:
(de SLA pactados) • Hoja seguimiento – Interlocutores
de ofertas – Comités
• Contrato (UC) – Informes
• Base datos – Interfaces
suministradores y
contratos (SCD)
PDCA
Mejora
SGSTI
Figura 7.3.8. Componentes más destacados del proceso
Los componentes principales que se emplean en el proceso son, por orden alfabé-
tico, los siguientes:
• Contrato. Documento legal que formaliza la compra o la contratación.
• Contrato de soporte (UC, Underpinning Contract). Término muy utilizado
en el ámbito de ITIL. Se refiere al contrato específico de servicios con un
suministrador externo en el que se fijan los niveles de servicio que el sumi-
nistrador debe cumplir. Los niveles de servicio pactados en los contratos de
soporte deben ser igual o más exigentes que los acordados con las áreas clien-
tes en los SLA.
• Declaración de requisitos (SOR, Statement Of Requirements). La declaración
de requerimientos es el término utilizado en ITIL v3 para referirse a la RFP.
• Estrategia de sourcing. La estrategia de sourcing determina qué actividades
o funciones se van a realizar internamente (retenidas) y cuales se van a con-
tratar al mercado (externalizadas). Determina así el perfil de externalización.

Además, pueden marcar directrices para la selección de los suministradores y
el marco de calidad y niveles de servicio a obtener.
• Hoja de petición de compra. Ficha con los datos de la compra que se pre-
tende realizar (detalle de los productos o servicios a contratar, área proponente,
elementos de configuración y servicios de TI a los que afecta, presupuesto asig-
nado, justificación, documentación de respaldo, etc.). La crea el área de TI que
tiene la necesidad, la aprueba el área financiera de TI y la completa la gestión
de suministradores a lo largo del ciclo de selección y contratación.
• Hoja de seguimiento de ofertas. Fichas con los datos económicos y carac-
terísticas de todas las ofertas recibidas para una solicitud de compra. Sirve
como base para analizar las diversas ofertas, en sus aspectos económicos y en
su contenido. Esta ficha suele contener el resumen de la valoración técnica y
económica de las ofertas.
• Interfaces entre los procesos de la organización de TI y el suminis-
trador. Para que la prestación de servicios sea eficiente, es necesario
que los procesos del proveedor de TI y del suministrador engranen a la
perfección. Las interfaces realizan la conexión entre los dos procesos.
Muchas veces serán interfaces informáticas entre las herramientas de ges-
tión de ambas organizaciones y otras serán interfaces o comunicaciones
humanas.
• Interlocutores. Rol que designa a los diversos representantes por parte de la
organización contratante y por parte de la organización contratada.
• Niveles de servicio (en UC). Al igual que la organización de TI compro-
mete unos niveles de servicio con el negocio firmando los SLA, en la con-
tratación con suministradores se deben fijar unos niveles de servicio, de
forma paralela, que sean capaces de soportar los compromisos adquiridos
de la organización de TI. Así, los UC deben estar alineados con los SLA,
contratando unos niveles de servicio homogéneos a los suministradores.
• Mecanismos de relación (con suministradores). Regula la relación entre la
empresa contratante y la empresa contratada. Define la interrelación entre
ambas partes, los comités, los roles de interlocución, los tipos de informes,
las métricas para el seguimiento del cumplimiento, la gestión de los aspectos
financieros y contractuales, las penalizaciones y reclamaciones, la gestión del
conocimiento, la confidencialidad, etc.
• Petición de compra (RFP, Request For Proposal). Documento que contiene
las especificaciones del producto o servicio que se pretende comprar y que se
utiliza para petición de ofertas al mercado. Su contenido suele tener carácter
contractual y pasa a formar parte del contrato final (está relacionado con otra
forma de emitir solicitudes de ofertas denominadas: ITT, Invitation To Tender).
Si se ha realizado un RFI previo, se toman sus resultados como punto de par-
tida. Toda compra importante debería llevar una RFP que especifique todos
los detalles y acuerdos de la compra. La RFP se remite a los suministradores
candidatos y suele formar parte del contrato final.
• Políticas de contratación. Directrices y normativas internas que dictan las
pautas establecidas en la estrategia de sourcing que se deben seguir en todas
las adquisiciones o contrataciones.
• Proveedor de TI. Organización, departamento, área de TI que presta los
servicios de TI. Es el contratante de los servicios de terceros que necesite
para ser capaz de proveer los servicios TI prestados al negocio.
• RFI (Request For Information). Petición de información, de ideas y de enfo-
ques que solicita la organización de TI a ciertos suministradores clave.
Mediante la RFI se plantea al mercado una situación y se le solicitan ideas y
posibles soluciones. Con los resultados de este sondeo se enfoca de forma
más precisa la contratación a realizar.
• SCD (Supplier and Contract Data base). Es la base de datos de suministrado-
res y contratos, que centraliza y registra toda la información sobre los con-
tratos realizados. Este término se ha acuñado en ITIL v3, aunque el con-
cepto ya era muy conocido en el mercado.
• Servicio. En lo relativo al término de servicio, surge un nuevo conflicto ter-
minológico, pues también se denomina servicio a la prestación contratada a
un suministrador. Por tanto, ya existen tres tipos de servicios:
– Los servicios que comercializa el negocio al mercado, que en algunas oca-
siones son servicios de TI puros.
– Los servicios que presta el proveedor o área de TI internamente a las áreas
de cliente de la empresa.
– Los servicios que presta un suministrador al proveedor o área de TI.
• Solicitud de ofertas (ITT, Invitation To Tender). Comunicado remitido a

los potenciales suministradores para la solicitud de ofertas formales para pro-
ceder a la contratación de servicios. La diferencia entre la RFP y una ITT
no está del todo clara y depende de los usos y hábitos en cada país o en cada
sector. En términos generales, en la ITT la carga de la descripción del pro-
ducto o servicio recaen en el suministrador, mientras que en la RFP la des-
cripción está contenida en la propia RFP (por ello, pasará a formar parte
del contrato final). El término ITT se utiliza en ITIL v3, mientras que en la
versión 2 se utiliza más RFP.
La RFP o la ITT son formas parecidas de solicitar ofertas al mercado para efec-
tuar una compra y, por tanto, deben tener asignado un presupuesto interno.
• Sourcing. El término sourcing comprende todas las actividades relativas al
aprovisionamiento de productos y a la provisión y el soporte de los servicios,
necesarias para poder prestar el servicio de TI. En los dos extremos del sour-
cing están: el outsourcing (externalización completa de una unidad de TI) y el
insourcing (realización de la actividad internamente por el personal de planti-
lla y subcontratado). Entre medias está el outsourcing selectivo (externaliza-
ción de funciones al mejor suministrador en cada una de ellas) y una amal-
gama de posibles subcontrataciones. La proporción de cada uno depende de
las políticas y estrategias de sourcing de la organización. Por tanto, el con-
cepto de sourcing va más allá de su traducción literal por “suministro”, pues
también incluye las actividades internas retenidas en la organización de TI.
• Subcontratistas. Empresas a las que un suministrador contrata a su vez algún
servicio necesario para prestar el servicio contratado con el proveedor TI.
• Suministrador de TI. Empresa externa al proveedor de TI que provee
algún producto, o presta algún de servicio a éste, bajo un contrato de com-
pra o de prestación. El abanico de suministradores es muy amplio y com-
prende a fabricantes de equipamiento hardware, fabricantes de productos
software, proveedores de telecomunicaciones, servicios mantenimiento hard-
ware y software, servicios de soporte, servicios de body shopping, consultores,
integradores, servicios de valor añadido, outsourcers de funciones específicas
de TI, outsourcers integrales, etc.
Conviene destacar que, para evitar la confusión terminológica, en las Nor-
mas ISO/IEC20000 se ha adoptado el término de suministrador para desig-
nar a toda organización a la que se le contrata algún tipo de prestación, que-
dando el término proveedor para aquellas organizaciones que quiere cumplir
con lo especificado por la norma (a efectos de certificación). Se distingue,
así, entre suministrador de TI y proveedor de TI (área o departamento de
TI). Esta consideración es muy importante en el ámbito de estas normas, y
hay que afinar el lenguaje, utilizando siempre suministrador para estas pres-
taciones contratadas externamente.
• Tipos de sourcing. Los tipos de sourcing son tan variados como tipos de ser-
vicios, o parte de los mismos, que se pueden contratar. Los tipos más fre-
cuentes en el mercado son: internalización o realización interna, prestación
de servicios o body shopping, outsourcing selectivo, y outsourcing completo.
Interrelación entre la gestión de suministradores y otros

procesos y áreas de TI
El proceso de gestión de suministradores da un servicio a otros procesos o áreas de
TI con el fin de canalizar en un punto la gestión del suministro externo. Pero, cada
tipo de producto o servicio contratado tiene unas características de gestión especí-
fica. Así:
• En los servicios con una gestión por proyecto (consultoría, desarrollo de soft-
ware, transformación de infraestructuras, etc.), el proceso lidera el ciclo de
selección y contratación, acompañado y soportado por el área solicitante.
Pero en la ejecución del proyecto, puede pasar a un segundo plano, dejando
que el jefe de proyecto lleve la gestión del suministrador.
• En la compra de productos (hardware, software, etc.), el proceso lidera tam-
bién el ciclo de contratación. La implementación la realizan las áreas técni-
cas bajo el proceso de gestión de la entrega. Vuelve a tomar un papel rele-
vante en la gestión de los contratos de mantenimiento y de soporte, para
garantizar su alineamiento con los niveles de servicio y controlar el desem-
peño del fabricante.
• En la contratación de servicios continuos (outsourcing, comunicaciones, hos-
ting de servidores, body shopping, mantenimiento de software, software facto-
ries, etc.), el proceso se despliega completamente en toda su extensión ya
que, además del ciclo de contratación, gestiona en todo su esplendor el ciclo
de prestación (en la faceta de control y seguimiento continuo), hasta la ges-
tión de la etapa de renovación o finalización.
La gestión de suministradores tiene una relación muy estrecha con el proceso de

gestión de nivel de servicio, pues se responsabiliza de la contratación y cumpli-
miento de los niveles de servicio de los suministradores para que garanticen o res-
palden los SLA con los clientes.
Siguiendo el ciclo de vida del servicio de ITIL v3, en la etapa de diseño del servicio
se realiza el ciclo de selección y contratación del suministrador, mientras que la
transición y la operación del servicio se relacionan con el ciclo de gestión de la pres-
tación del suministrador. La etapa de operación participa en la actividad de renova-
ción o finalización.
En muchas organizaciones, la función de compras se centraliza en un departamento
fuera de TI, que suele llevar a cabo el ciclo de selección y contratación del servicio. El
departamento de compras dispone de personal especializado en la contratación de pro-
ductos o servicios de TI. En este escenario, el proceso de gestión de suministradores se
extiende más allá de la organización de TI hacia el departamento de compras para

engranar la estrategia de sourcing de TI con las políticas de compras.

El proceso de gestión de suministradores se encarga de garantizar al resto de la
organización de TI que se alcanzan los objetivos contemplados en los contratos
externos de suministro, de soporte, de consultoría, etc. velando por la mínima fric-
ción entre las diferentes organizaciones. Las entradas, actividades y salidas del pro-
ceso se muestran en la figura 7.3.9.
Las entradas que activan el proceso son la definición o modificación de la estrate-
gia de sourcing, que activa las acciones necesarias para la revisión de las políticas de
Desencadenantes 3 Etapa de planificación e Salidas principales:

del proceso: implementación del proceso. Ü Producto o servicio
Ü Modificación en la 3 Definición de la estrategia de contratado y
estrategia de sourcing. sourcing. prestándose a TI.
Ü Necesidad de compra 3 Ciclo de selección y contratación: Ü Contrato firmado.
(hoja petición compra). • Identificación de la necesidad y Ü SCD actualizada.
Ü Petición de SLM. preparación del caso de negocio. Ü Informes seguimiento
Ü Necesidad de TI • Evaluación y provisión de nuevos del suministrador.
en relación a contratos y suministradores. Ü Sistemas de gestión
suministradores. • Establecimiento de nuevos TI-suministrador
suministradores y contratos. interconectados.
• Categorización de
Ü Estrategia y políticas Salidas secundarias:
suministradores y
de sourcing. Ü RFI, RFP, ITT enviadas
mantenimiento de la SCD.
Ü Especificaciones de la al mercado.
compra (RFP o SOR). 3 Ciclo de gestión de la prestación:
Ü Reuniones con
gestión y desempeño de
Ü Caso de negocio asociado suministradores.
suministradores y contratos.
la compra. Ü Actas de las reuniones.
3 Etapa de renovación o de
Ü SLA firmados. Ü Contactos entre TI y
finalización de contratos.
Ü CMDB. suministrador.
3 Supervisión funcionamiento
Ü Presupuestos. del proceso. Mejora del Ü Actualización de la
propio proceso. CMDB.
Ü Propuestas de mejora del
proceso.
Fuente: e.p. y Libro ITIL Diseño del Servicio publicado por OGC.

contratación y desencadena la ejecución de la nueva estrategia en relación al aprovi-

sionamiento; una necesidad de una compra o contratación de un servicio, remitida
desde otras áreas de TI mediante la hoja de petición de compra, para que el pro-
ceso realice la selección y contratación del producto o servicio; una petición de la
gestión de nivel de servicio (SLM) relativa a los suministradores (alineamiento de
los niveles de servicios, reunión con un suministrador, informes, etc.); y cualquier
necesidad del área de TI en relación a los suministradores, peticiones diversas de la
dirección de TI o de otras áreas.
Las entradas relevantes de soporte o auxiliares que utiliza el proceso en el desarrollo
de su actividad son la estrategia general de sourcing de la empresa, así como, las direc-
trices para su ejecución contenidas en las políticas de sourcing; la documentación pre-
via generada que acompaña a la petición de compra (RFI, RFP o SOR, el caso de
negocio justificativo de la compra, si procede, etc.); los acuerdos de nivel de servicio
firmados con los clientes, con el fin de garantizar que los suministradores son capaces
de respaldar estos niveles de servicio; información sobre los diversos elementos de
configuración contenida en la CMDB; y el detalle de los presupuestos disponibles,
con el fin de ajustar las políticas y contrataciones a los límites presupuestarios.
Se entiende como una salida principal del proceso el producto que se pretende comprar
ya suministrado y operativo, y la necesidad de un servicio externo prestándose y gestio-
nado, en tanto en cuanto el proceso tiene como misión controlar la adecuada prestación
de los servicios y productos contratados. No es de su responsabilidad, obviamente, la
ejecución de tareas propias de prestación del mencionado servicio o producto.
También se consideran salidas principales del proceso los contratos de soporte firma-
dos (UC); la base de datos de suministradores y contratos (SCD) creada y actuali-
zada; los diversos informes de seguimiento de los suministradores realizados (calidad
del servicio, satisfacción, desempeño, etc.); sin olvidar la interconexión entre los siste-
mas de gestión de TI y del suministrador, en aquellos casos en los que sea necesario.
El proceso también genera otro tipo de salidas de menor relevancia o secundarias.
Éstas son la emisión de RFI, RFP o ITT al mercado para la contratación, las reu-
niones realizadas entre suministradores y la organización de TI; las actas de las reu-
niones; los contactos entre TI y el personal del suministrador de soporte; la CMDB
actualizada; las propuestas de mejora del proceso; etc.
Las Normas ISO/IEC 20000 definen los siguientes requisitos introductorios para
este proceso:
UNE-ISO/IEC 20000-1
El proveedor del servicio debe tener documentados los procesos de gestión de suminis-
tradores y debe designar un gestor responsable del contacto con cada suministrador.
Los SLAs con los suministradores se deben alinear con los SLAs con el negocio.
Las interfaces entre los procesos utilizados por cada parte deben ser acordadas y docu-
mentadas.
Todos los roles y relaciones entre suministradores principales y subcontratados deben
estar claramente documentados. Los suministradores principales deben ser capaces
de demostrar que tienen procesos para garantizar que los subcontratistas cumplen
con los requisitos contractuales.
Se debe disponer de un proceso para la revisión detallada del contrato o del
acuerdo formal, con periodicidad mínima anual, que garantice que las necesidades
y obligaciones contractuales del negocio se siguen cumpliendo.
UNE-ISO/IEC 20000-2
Los procedimientos de gestión de sumi- c) los cambios son gestionados;

nistradores deberían garantizar que:
d) se registran las transacciones de
a) el suministrador entiende sus obli- negocio entre todas las partes;
gaciones frente al proveedor del
e) se puede controlar la información
servicio;
sobre el desempeño de todos los
b) los requisitos acordados y legítimos suministradores y actuar en conse-
son cumplidos dentro del alcance y cuencia.
los niveles de servicio acordados;
El proceso, que en este libro se inicia con la estrategia de sourcing y definición de

las políticas de suministro y contratación, se responsabiliza también de la ejecución
de las contrataciones, para posteriormente, realizar el seguimiento de toda la pres-
tación del servicio, hasta la necesidad de renovación o finalización. En los aparta-
dos siguientes se detallan estas actividades siguiendo la estructura indicada en la
figura 7.3.10.
Estrategia Selección y Gestión de

Finalización
de sourcing contratación la prestación
Figura 7.3.10. Estructura del proceso de gestión de suministradores

utilizada en este libro
Estrategia de sourcing
La estrategia de sourcing forma parte de la estrategia general de TI. En la estrategia
de sourcing se definen las actividades que se realizarán internamente en la organiza-
ción de TI y las actividades que se externalizarán. Por tanto, la estrategia de sourcing
define la forma en que se cubrirán las necesidades para la creación y prestación de los
servicios. Abarca tanto a las áreas de desarrollo como las de producción o explota-
ción, contemplando todo tipo de funciones de TI (planificación y control, arquitec-
tura, programación, operación, técnica, etc.). Para todas ellas, se define que activida-
des se realizarán internamente y en cuáles se recurrirá al apoyo de suministradores.
Además, la estrategia de sourcing refleja la visión final deseada en cuanto al mapa de
suministradores, definiendo si habrá una concentración de suministradores o una
atomización de los mismos, el número idóneo de suministradores deseado, etc.
La estrategia de sourcing define los tipos de servicios que puede contratar la organi-
zación de TI. Éstos son de muy diversa índole. En la figura 7.3.11 se muestran
diversos ejemplos de tipos de contrataciones que se podrían realizar.
Ejemplos de contrataciones
3 Compra de hardware y software.

3 Mantenimiento de hardware y software.
3 Soporte de fabricante.
3 Proyectos llave en mano de desarrollo de software.
3 Contratos de mantenimiento de aplicativos.
3 Consultoría y asesoría.
3 Diseño técnico o funcional.
3 Prestación de servicios Body Shopping.
3 Contratación de un “servicio”: comunicaciones,
ASP, provisión del PC.
3 Externalización de un proceso de negocio.
3 Externalización de una función o área de TI
(call center, monitorización, hosting).
3 Consolidación de proveedores.
3 Contratación de un bloque en modo servicio.
3 Outsourcing de la administración.
3 Renting de la infraestructura.
3 Outsourcing selectivo.
3 Outsourcing completo.
Figura 7.3.11. Diversos tipos de aprovisionamiento en la organización de TI

La definición de la estrategia de sourcing contempla cinco actividades 1: la identifi-

cación de la situación de partida, el análisis del mercado, el diseño de escenarios, la
realización del caso de negocio y la toma de la decisión de la estrategia que se debe
seguir y su implementación. En la figura 7.3.12 se muestran estas 5 actividades.

Finalización
Actividades de la estrategia de sourcing
• Identificación de la estrategia de la empresa (objetivos) y análisis de la situación

de partida (capacidades).
• Análisis del mercado, identificación de la oferta existente.
• Diseño y análisis de los escenarios alternativos.
• Realización del caso de negocio.
• Decisión e implementación de la estrategia.
Fuente: Gartner y e.p.
Figura 7.3.12. Actividades en la definición de la estrategia de sourcing
Un aspecto importante de la definición de la estrategia de sourcing es la determina-

ción del modelo de control y supervisión del mismo ya que, si este es muy ligero
no se tendrán garantías en el cumplimiento de lo contratado, mientras que si el
control es muy pesado se generará un sobre esfuerzo de gestión importante, tanto
en el suministrador, como en la organización de TI.
Otro aspecto importante es la identificación, para cada uno de los ámbitos de TI,
de las actividades que deben ser retenidas y aquéllas que pueden ser externalizadas.
De forma general, al efecto de delimitar el alcance de una externalización, las acti-
vidades de TI se pueden tipificar en: estratégicas, de control, de planificación, de
relación, de supervisión, de arquitectura, de diseño, de construcción, técnicas
de detalle, de administración, de operación y de atención. Para cada uno de estos
1
Documento: Best practices for creating an IT service sourcing strategy. Gartner 2007.
tipos, se debe definir cuáles de sus actividades se deben retener y cuáles se pueden
externalizar (véase el ejemplo de la figura 7.3.13).
Funciones de TI Estrategia de sourcing
– Dirección Retener + consultoría estratégica y coaching
Relación Retener + personal de apoyo externo

Volumen de personas
Gestión Retener
involucradas
Control Retener
Definición técnica Retener + proyectos externos arquitectura
Tecnológicas Externalizar
+ Operativas Externalizar
Figura 7.3.13. Ejemplo de un enfoque para la estrategia de sourcing

de las funciones TI
Desarrollando el ejemplo de la figura 7.3.13, si se añaden ahora en columnas las

áreas que conforman la organización de TI (en este ejemplo se ha seguido un
esquema clásico de 4 áreas: gobierno de TI, arquitectura funcional y técnica, desa-
rrollo de software y producción o explotación de servicios) se tiene un mayor detalle
de las funciones que se pueden externalizar por cada área. De esta forma, en la
figura 7.3.14 se muestra la aplicación de una estrategia homogénea de externali-
zación de las funciones tecnológicas y operativas tanto para el desarrollo, como
para la producción (en este ejemplo la gestión tecnológica y las funciones operativas
se externalizan).
En un tercer nivel de detalle (nivel de servicio), en la estrategia de sourcing se debe
definir la estrategia de suministro que se seguirá y el grado de consolidación de
suministradores objetivo. Como es lógico, el perfil de externalización también
puede variar según el tipo de servicio de TI del que se trate. En la figura 7.3.15
se muestra otro ejemplo de estrategia de sourcing con una externalización fuerte, se
detalla para cada servicio de TI siguiendo el ciclo de vida del servicio. En este caso,
la estrategia para el puesto de trabajo se focaliza en la contratación de algunos
servicios ofrecidos en forma de producto por el mercado como, por ejemplo, el puesto
cliente gestionado (suministrador A), el correo electrónico en modo servicio
Gobierno
Funciones de TI Arquitectura Desarrollo Producción
de TI
Dirección INTERNO INTERNO INTERNO INTERNO
Relación INTERNO INTERNO INTERNO INTERNO
Internalizado
Gestión INTERNO INTERNO INTERNO INTERNO
Control INTERNO INTERNO INTERNO INTERNO
Definición técnica INTERNO INTERNO INTERNO
Externalizado
Tecnológicas EXTERNO EXTERNO EXTERNO
Operativas EXTERNO EXTERNO
Frontera típica
de externalización INTERNO Internalizado EXTERNO Externalizado
Figura 7.3.14. Ejemplo de la frontera de externalización
Mejora
Estrategia Diseño Construcción Transición Operación
continua
Servicios TI
• PC, LAN,
INTERNO INTERNO
ficheros
SUMINISTRADOR A
• Movilidad
INTERNO INTERNO
(WIFI+RAS)
• eMail INTERNO SUMINISTRADOR B INTERNO
• CRM INTERNO INTERNO SUMINISTRADOR C
• Facturación INTERNO INTERNO SUM. D INTERNO SUMINIS. E INTERNO
• ERP INTERNO INTERNO SUMINISTRADOR F
• Comunica-
INTERNO SUMINISTRADOR G INTERNO
ciones WAN
Diversos
INTERNO Internalizado SUM. n
suministradores
Figura 7.3.15. Ejemplo de definición de una estrategia de outsourcing selectivo

a nivel de servicio de TI, detallada según el ciclo de vida del servicio
externo (suministrador B) o la externalización completa de las comunicaciones

(suministrador G). En el caso de los servicios de aplicaciones de negocio, la estrate-
gia de sourcing diferencia entre los suministradores de construcción y transición
(suministradores C, D y F), frente al suministrador de operación (suministrador E);
reteniéndose la estrategia y el diseño.
Desarrollando otro ejemplo en el ámbito concreto de la operación, las actividades
que se podrían traspasar hacia el territorio de los suministradores en una estrategia
de externalización de las funciones operativas reteniendo la gestión y el control
serían las siguientes:
• Resolución de incidentes. La realización por el suministrador de funciones
en la resolución de incidentes, como:
– La atención telefónica en el service desk.
– La primera línea de soporte.
– El soporte técnico general (segunda línea de soporte).
– El soporte especializado del fabricante (tercera línea).
• Peticiones. Una parte o el total de la gestión de las peticiones en el catálogo

de servicios por parte del usuario.
• Resolución de problemas. La participación especializada de suministra-
dores en la resolución de problemas.
• Gestión de la configuración. La actualización de los elementos de configura-
ción en los que interviene el suministrador (nuevos productos, actuaciones, etc.).
• Gestión del cambio. Normalmente la participación del suministrador pro-
viene de su intervención en proyectos de desarrollo o de infraestructuras.
• Gestión de la entrega. Algunas funciones operativas en el despliegue de
entregas.
• En actividades de la gestión de la capacidad, de la disponibilidad y de la con-
tinuidad.
• Infraestructuras. En el diseño de soluciones de infraestructuras, en su ope-
ración, en el soporte técnico o en el despliegue de las mismas.
En el ámbito de la estrategia de sourcing, se suele contemplar la definición de un

conjunto de suministradores estratégicos según el tipo de servicio que se va a con-
tratar. Se realiza una homologación de suministradores y se establecen de tarifas en
base a un catálogo de los servicios que se pueden externalizar. Así, se concretan una
serie de suministradores predefinidos de servicios homologados y caracterizados

según las fases del ciclo de vida de los servicios de TI, asociados a las tecnologías
que conocen y a las actividades que pueden realizar. Para agilizar las tramitaciones,
con este tipo de suministradores se desarrollan unas políticas internas de contrata-
ción más ligeras y con preautorizaciones establecidas.
La estrategia de sourcing tiene tal importancia en TI que, con frecuencia, a la lle-
gada de un nuevo director de TI, la consolidación de suministradores o la imple-
mentación de un tipo de outsourcing se convierten en los estandartes para una trans-
formación radical.
Ciclo de selección y contratación de productos y

servicios
Una vez definida la estrategia de sourcing entra en acción el primer ciclo de gestión
de suministradores, destinado a la selección y contratación de productos y servi-
cios. Este ciclo se activa con una necesidad de compra, que surge de la ejecución de
la cartera anual de proyectos, de un plan de capacidad o de cualquier otra demanda
puntual. Como su nombre indica, el propósito de esta actividad o ciclo es la selec-
ción de los suministradores y la adquisición de productos y servicios.
Es importante recordar en este punto que, como se ha señalado anteriormente, la
parte del ciclo dedicada a la selección de suministradores no forma parte del alcance
y requisitos de las Normas ISO/IEC 20000, pero que se incluye, al igual que la
actividad anterior, a efectos de completitud en la descripción de la gestión de sumi-
nistradores.
Este ciclo de selección y contratación transcurre vinculando el área de la empresa
encargada de gestionar las compras (normalmente externa a TI). En esta situa-
ción, la organización de TI actúa como unidad solicitante y que presenta la nece-
sidad de la adquisición. Ambas áreas trabajan de forma estrecha en el mismo
proceso; el área de compras gestionando y formalizando la relación con el exte-
rior, y la unidad solicitante aportando el conocimiento técnico relativo al objeto
de la adquisición.
El ciclo comienza con la definición de las especificaciones del producto o servicio
que se va a adquirir, realizadas en la etapa de diseño del servicio o en otros proce-
sos o áreas de TI. Dependiendo de cada caso particular, después de las especifica-
ciones se realizará y aprobará el caso de negocio (business case o estudio que analiza
los costes y beneficios que aporta un proyecto), se emitirá una consulta al mercado
o RFI, se confeccionará la especificación de compra o RFP, se creará la hoja de
petición de compra, etc.
Dado que los tipos de adquisiciones gestionados pueden ser muy diversos, desde
un equipamiento sencillo, pasando por un proyecto llave en mano, hasta la contra-
tación de un servicio de externalización a varios años, es necesario que los procedi-
mientos existentes se adapten a la envergadura y criticidad de cada tipo de adquisi-
ción. En las simples y repetitivas, bastará con una sencilla hoja de petición de
compra. En cambio, en los grandes proyectos será necesario recorrer todas las eta-
pas: la RFI, pasando por el caso de negocio, la aprobación de la inversión, la gene-
ración de la RFP, etc.
Incorporando la estructura de las actividades definidas en ITIL v3 a este ciclo de selec-
ción y contratación queda un esquema como el que se muestra en la figura 7.3.16.

Finalización
• Necesidad de TI.
• RFI.
Actividades de selección y contratación • Caso de negocio.
• RFP (SOR).
• Hoja de compra.
• Identificación de la necesidad y preparación del caso de negocio • Asiento de la petición
de compra en el ERP.
• Evaluación y provisión de nuevos contratos y suministradores • Hoja seguimiento
de ofertas.
• Implementación de nuevos suministradores y contratos
• Contrato (UC).
• Categorización de suministradores y mantenimiento de la SCD • Base de datos

suministradores
y contratos (SCD).
Figura 7.3.16. Principales actividades del ciclo de selección y

contratación de suministradores
A continuación se resume el alcance de estas actividades.

Identificación de la necesidad y preparación del caso de negocio Actividad que
realiza el área de TI solicitante dentro del proceso de gestión de suministradores,
actuando para un nuevo proyecto de creación o evolución de servicios o para satis-
facer cualquier otra necesidad. En esta etapa se realiza:
• La definición de la necesidad de adquisición.
• La confección de la RFI, solicitud de emisión al mercado y análisis de las res-
puestas (si procede).
• La realización del caso de negocio o business case (si procede).

• La presentación al comité de inversiones o a la dirección de TI para su apro-
bación (si procede).
Como se ha apuntado, la realización del caso de negocio o business case sólo se reco-
mienda en las grandes inversiones. Se analizarán las alternativas, los costes y los
beneficios del proyecto tanto para el negocio, como para la organización de TI.
Una vez realizado, el comité de inversiones o la dirección de TI decidirán si es idó-
neo llevarlo a cabo y la alternativa más adecuada. El caso de negocio y la gestión de
la aprobación del presupuesto asociado los suele realizar el área proponente traba-
jando para el proceso de gestión de suministradores. La estructura y el contenido
tipo de un caso de negocio deben estar estandarizados en la organización para evi-
tar reinventar continuamente la rueda y reducir el tiempo de su confección. Para la
realización de los casos de negocio se necesita información de los costes unitarios y
totales de la actividad, de los mantenimientos, de las amortizaciones, etc. Esta
información analítica de los costes conviene recogerla y mantenerla centralizada
para los diversos estudios que se realicen. En la figura 7.3.17 se muestra un ejem-
plo de estructura de un caso de negocio.
De forma previa a la realización del caso de negocio, puede ser necesario hacer una
consulta o petición de ideas (RFI) a los proveedores principales, que pudieran dar
una orientación sobre la solución más adecuada. La RFI permite realizar una pros-
pección del mercado en un ámbito en el que no se tiene experiencia y, en cierta
manera, ahorra la contratación de una consultoría externa. La RFI también la rea-
liza el área proponente de la compra y, en contra de la práctica habitual, siempre lo
debe remitir al mercado el área de compras, ambas trabajando bajo este proceso de
gestión de suministradores.
Evaluación y provisión de nuevos contratos y suministradores. Esta etapa se

centra en desarrollar el proceso de contratación, que finaliza con la licitación adju-
dicada a un suministrador y el contrato formalizado. Las actividades que se suelen
contemplar (inspiradas en ITIL v3) son las siguientes:
• Creación de la especificación de compra o RFP, documento que se enviará a
los suministradores candidatos.
• Preparación de la hoja de petición de compra, documento interno con los
datos de centros de coste, plazos, estimación de recursos y presupuesto de la
compra.
• Registro de la petición de compra en el sistema de gestión de la empresa
(ERP) para su aprobación presupuestaria.
Estudio de negocio (business case )
3 Descripción del alcance:

• Breve descripción y funcionalidades.
• Objetivos a alcanzar.
• Ámbito de aplicación y relaciones con otros
servicios.
• Ámbito temporal.
3 Justificación de la necesidad.
3 Tendencias del mercado. Referencias externas.
Benchmarking externos.
3 Presentación de alternativas o soluciones posibles.
Realización interna-externa, compra-desarrollo.
3 Estimación del coste total de propiedad a 3 o 5 años
de cada alternativa.
3 Beneficios cualitativos esperados.
3 Beneficios cuantitativos esperados.
3 Análisis de escenarios posibles y riesgos
3 Recomendaciones y conclusiones.
3 Anexos:
• Costes totales y unitarios del negocio.
• Costes totales y unitarios de TI.
Figura 7.3.17. Ejemplo de la estructura de un caso de negocio

para un proyecto importante
• Envío de la petición de compra al área de compras. Recepción, registro y

validación de la hoja de petición de compra.
• Identificación del método de compra o del suministro más adecuado.
• Establecimiento de los criterios de evaluación: calidad, coste, capacidad de
ejecución, experiencia, etc.
• Selección de posibles suministradores.
• Remisión de la RFP (por el área de compras) a los proveedores selecciona-
dos para que concursen, se especifica un período de preguntas.
• Recepción de ofertas, revisión y homogeneización de las mismas (si es nece-

sario).
• Evaluación de las ofertas, en sus aspectos técnicos y comerciales. La evalua-
ción técnica la realiza el área proponente, mientras que la comercial la realiza
el área de compras. Realización de las hojas de seguimiento de ofertas.
Como resultado de la evaluación se obtiene si una oferta es adecuada o no, y
cuánto es mejor una oferta que otra, expresada en un diferencial económico,
técnico o mixto.
• Negociación de las ofertas y adjudicación a un suministrador.
• Negociación del contrato, objetivos, términos y condiciones.
• Acuerdo y formalización del contrato.
En adquisiciones importantes es extremadamente importante la elaboración de un

documento con las especificaciones detalladas de la compra que se va a realizar
(RFP o SOR). Normalmente, la RFP es relativa a la contratación de servicios, aun-
que también se debe realizar para grandes compras de equipamiento. En la RFP se
definen todas las características del servicio que se pretende adquirir: alcance, des-
cripción de los servicios a prestar, entorno en el que se prestarán los servicios, equi-
pamiento involucrado, niveles de servicio a cumplir, resultados a entregar, condi-
ciones de prestación, penalizaciones, etc. La estructura de la RFP debe estar
tipificada y adaptada al tipo de compra, por ejemplo, un desarrollo llave en mano,
un proyecto de consultoría, un servicio de externalización de las operaciones, etc.
El escenario en el que la RFP alcanza su máximo esplendor y relevancia es en la
contratación de servicios de outsourcing. En este caso, la confección de la RFP pude
llevar varios meses, en los que se realiza un inventario previo de todos los elemen-
tos que se van a gestionar (denominado línea base o baseline) y se especifica con
detalle los servicios a recibir. Este documento será parte integrante del contrato
posterior. En la figura 7.3.18 se muestra un esquema ejemplo de una RFP enfo-
cada a la externalización de un servicio.
La RFP se confecciona por el área solicitante y su preparación se considera una
actividad propia de este proceso (ITIL v3 la enmarca en el libro Diseño del Servicio).
Es importante recalcar que la comunicación con el entorno exterior siempre se
debe realizar de forma canalizada a través la unidad de compras. Las diversas áreas
de TI no deberán enviar por su cuenta ningún tipo de comunicado o documenta-
ción para la contratación a los futuros suministradores, ni siquiera la RFI.
El último documento que debe realizar el área solicitante es una petición interna de
compra, expresada en forma de hoja de petición de compra. Esta petición adjunta
Especificación de compra
(RFP o SOR) enfocada
a una externalización
3 Términos básicos y condiciones: 3 Condiciones comerciales:

• Objetivo y alcance. • Coste del servicio y forma de pago.
• Duración del contrato.
3 Penalizaciones:
• Definiciones.
• Penalizaciones e incentivos.
• SLA y OLA de referencia. Régimen de pago variable
• Estándares a cumplir. según cumplimiento.
• Partes implicadas: suministrador,
3 Responsabilidades y dependencias:
unidad TI.
• Responsable de planificación e
3 Descripción del servicio a contratar: implantación de servicios nuevos o
• Objetivo y alcance del servicio. modificados.
• Funcionalidades del servicio. • Responsable de nivel de servicio.
• Ámbito de aplicación y relaciones • Proveedores de servicios externos.

con otros servicios.
3 Requisitos para la etapa de
3 Características del servicio transición.
a contratar: 3 Etapa de finalización del contrato.
• Funcionales.
3 Inventarios base (baseline).
• Horario de servicio y soporte,
disponibilidad y fiabilidad. 3 Información que se requiere del
oferente.
• Niveles de servicio pactados.
Rangos para la carga de trabajo. 3 Criterios para selección o
• Continuidad y seguridad, descalificación de propuestas.
rendimiento. 3 Fechas relevantes, incluyendo las
• Modelo relación e interfaces de apertura y cierre del proceso.
técnicas. Fechas para entrevistas y visitas.
• Explotación y operación, etc. 3 Requerimientos de confidencialidad.
3 Mecanismos de control y seguimiento 3 Elementos legales del contrato.
del servicio:
Etc.
• Indicadores y métricas para
controlar los niveles de servicio.
• Informes de gestión.
Figura 7.3.18. Ejemplo de RFP para la contratación

de un servicio de externalización
toda la documentación previa que ha debido preparar el área de TI solicitante.

Dependiendo del tipo y de la importancia de la adquisición puede contener los
resultados de la RFI, el caso de negocio, la decisión del comité de inversión, la
especificación de la compra RFP o SOR, la documentación del proyecto, etc.
Recuerde que no es necesario realizar todos estos documentos en todas las adquisi-
ciones. En las políticas de creación de nuevos servicios y en las de gestión de sumi-
nistradores se determinarán qué tipo de documentación se debe generar en cada
tipo de adquisición.
La petición de compra y su presupuesto se introducen en el sistema de gestión
general de la empresa (ERP) para su ciclo de aprobación formal.
La hoja de petición de compra, generada por el área de TI solicitante, desencadena
el resto del ciclo de selección y contratación. El primer paso será la generación de
una hoja o ficha de seguimiento de las ofertas, que esta vez realiza y mantiene el
área de compras. Esta hoja contiene todos los datos resumidos de la adquisición y
de las diversas ofertas recibidas. Incluye el detalle de los precios y de los contenidos
técnicos de las diversas ofertas. Mantendrá un mismo formato para registrar todas
las ofertas, de esta forma, se homogeneiza y sintetiza en una ficha toda la informa-
ción remitida por los suministradores en sus diversas ofertas. En adquisiciones
complejas, se puede descargar parte de este trabajo en el suministrador exigiéndole
que consigne los datos básicos de la adquisición en el formato especificado para
esta ficha. Como se ha indicado, la ficha de seguimiento de las ofertas también
incorpora las valoraciones técnicas y comerciales realizadas. Quizá la forma más
sencilla de almacenar estas fichas sea en archivos de hoja de cálculo.
En la figura 7.3.19 se muestra la estructura ejemplo de una hoja de petición de
compras y de una hoja de seguimiento de ofertas.
Establecimiento de nuevos suministradores y contratos. El propósito de esta

actividad es garantizar no sólo la correcta recogida y gestión de los contratos for-
malizados como resultado de la actividad anterior, sino también garantizar que se
tienen en cuenta otros aspectos fundamentales en la relación con los suministrado-
res seleccionados (por ejemplo, el riesgo asumido por ambas organizaciones),
como paso previo a su incorporación formal al registro de suministradores.
A efectos prácticos, tomando como referencia lo especificado por ITIL v3, el con-
junto de tareas objeto de la presente actividad son las siguientes.
• Incorporación del servicio del suministrador y del contrato, tanto dentro de
la base de datos de suministradores y contratos (SCD), como en el resto de
sistemas corporativos que así lo requieran (por ejemplo, en el sistema de ges-
tión de recursos o ERP).
Hoja de petición de compra Hoja seguimiento de ofertas
3 Título de la compra. 3 Título de la compra.

3 Área proponente y persona de 3 Hoja de petición de compra asociada.
contacto.
3 Histórico de ofertas recibidas en
3 Código de gasto y presupuesto el proceso de negociación por cada
asignado. proveedor, con el detalle de precios
y características.
3 Fechas y plazos a cumplir en la
compra. 3 Tabla desglose y comparativa
de precios.
3 Breve descripción y justificación de
la compra. 3 Valoración técnica y comercial de
las ofertas recibidas.
3 Detalles y volumetrías de la compra
(perfiles a contratar, número de 3 Personal interviniente en el proceso:
jornadas, etc.). Cálculo estimativo propio y de los suministradores
del presupuesto.
3 Documentación remitida por los
3 Proveedores propuestos. suministradores concursantes.
3 Antecedentes y condicionantes de 3 Modelo de negociación seguido.
la compra.
3 Documentación asociada a la compra:
proyecto, caso de negocio, RFI
anteriores, RFP o SOR, etc.
3 Comentarios y aclaraciones.
Elaborada por el área TI proponente Elaborada por el área de compras
Figura 7.3.19. Ejemplo de estructura de las hojas de petición de compra

y de seguimiento de ofertas
• Establecimiento de los contactos y relaciones. Designación de interlocutores

e implementación del resto de mecanismos para la gestión de la relación.
• Transición del servicio. Fase transitoria en la que el nuevo suministrador
asume el servicio, se integran procedimientos y se interconectan las herra-
mientas de gestión. En esta fase los niveles de servicio suelen ser menos
exigentes que en la etapa de prestación del contrato. Las actividades que se
realizan van desde la codificación hasta la integración, pruebas, elaboración
de documentos de uso, traducciones, revisiones de documentación o de usa-
bilidad, etc.
De acuerdo con lo especificado en las Normas ISO/IEC 20000, toda incorpora-

ción de nuevos suministradores o contratos, así como la modificación de los mis-
mos, será gestionada por el proceso de gestión del cambio, de tal forma que se ase-
gure que se evalúan y se comprenden todos los posibles impactos. El proceso
de gestión de suministradores actúa como propietario de la SCD (base de datos de
suministradores y contratos) fuente principal de información para la ejecución
de sus actividades.
Categorización de suministradores y mantenimiento de la SCD. Esta etapa se

centra en la categorización y evaluación de los suministradores para poner foco en
la gestión de los contratos importantes frente a los menos importantes. Como
resultado de la evaluación y categorización de suministradores, también es respon-
sabilidad de esta actividad asegurar el mantenimiento actualizado de la base
de datos de suministradores y contratos (SCD). Igual que en el caso anterior, de
acuerdo con lo descrito por ITIL v3, las tareas principales de esta actividad son:
• Categorización de los suministradores. Se recomienda realizarlo en función
de dos ejes: su valor-importancia y su riesgo-impacto. Así, se obtiene de
forma general una categorización que permite dosificar el esfuerzo y las
actuaciones, en los siguientes tipos:
– Estratégicos. Contempla alianzas y relaciones a largo plazo.
– Tácticos. Para aquellos suministradores con relaciones que involucran
gran volumen de actividad e interacciones de negocio.
– Operacionales. Para los suministradores de productos y servicios opera-
cionales.
– Básicos (commodity). Para los suministradores de productos y servicios de
bajo valor fácilmente suministrables, ya sea por la naturaleza del suminis-
tro o bien por la abundancia de suministradores.
• Evaluación o reevaluación del suministrador y del contrato, obteniendo una
calificación de su desempeño, y un registro de los éxitos y conflictos.
• Actualización de la SCD.
• Mantenimiento continuo de la SCD.
La base de datos de suministradores y contratos (SCD)

Esta base de datos aloja todo el conocimiento existente sobre los suministradores y
sobre los contratos efectuados. La SCD debe almacenar información útil para la
gestión de cada contrato, producto o servicio, y de los suministradores. Debe alo-

jar los archivos con la versión firmada de los contratos, información sobre el his-
tórico de la relación con el suministrador, los servicios contratados a cada uno, los
niveles de servicio, los costes, las fechas de renovación, las personas de contacto, el
personal de TI que ha ido participando en la relación, los principales éxitos y con-
flictos, etc.
La SCD se compone, como mínimo, de dos estructuras lógicas: las fichas de los
suministradores y las fichas de los contratos. En la figura 7.3.20 se muestra un
ejemplo del contenido de una SCD.
Estructura de la base de datos de

suministradores y contratos (SDC)
Fichas de suministradores:
3 Código y nombre del suministrador.
3 Contactos principales.
3 Contratos realizados.
3 Volumen total contratado por ejercicios.
3 Valoración del suministrador.
Fichas de contratos:
3 Código y título del contrato.
3 Servicios contratados. Descripción.
3 Niveles de servicio a cumplir.
3 Importe contratado.
3 Fechas y período del contrato.
3 Fecha límite para la comunicación de la terminación
del contrato.
3 Valoración de los resultados del contrato.
3 Éxitos y conflictos surgidos.
Relaciones:
3 Tipos de relaciones y procedimientos.
3 Interlocutores para cada una de ellas.
3 Interfaces entre herramientas.
3 Histórico de la relación.
Figura 7.3.20. Estructura ejemplo de la SCD

Contratos de Soporte (UC, Underpinning Contracts)
Dentro de los diversos tipos de contratos existentes entre la organización de TI y

sus suministradores destaca la figura tradicional de los contratos de soporte (UC),
pues son los que extienden la organización de TI para delegar una parte de la pres-
tación de los servicios en empresas externas. El foco principal en estos contratos es
reflejar todos los acuerdos en el proceso de negociación, con especial énfasis en la
alineación con los niveles de servicio comprometidos por la organización de TI con
los clientes.
UNE-ISO/IEC 20000-1
Los requisitos, alcance, nivel de servicio y procesos de comunicación a ser propor-

cionados por el suministrador(es) se deben acordar por todas las partes y documen-
tar en los SLAs u otros documentos.
Los SLAs con los suministradores se deben alinear con los SLAs con el negocio.
El contrato de soporte es un documento vinculante legalmente entre la organización

de TI y un suministrador externo, por tanto utilizará el formato de contrato habitual
de la empresa, o en su defecto usará el propuesto por el suministrador. Este contrato
define el objetivo, alcance y características del servicio que se va a prestar.
El contrato de soporte debería reflejar conceptos similares a los SLA utilizados, en
la figura 7.3.21 se muestra un ejemplo de su estructura.
Ciclo de gestión de la prestación de los servicios

contratados
Una vez cerrado el contrato con el suministrador se inicia la prestación de los servi-
cios contratados. Hay que tener en cuenta que la etapa de transición al nuevo servi-
cio se realiza en el ciclo anterior de selección y contratación (siguiendo ITIL v3).
Con el fin de garantizar la eficiencia del día a día en la prestación de los servicios
del suministrador, aparece el ciclo de gestión de la prestación, que sin interponerse
en la realización de las actividades del día a día, estructura, organiza y supervisa
todo lo necesario para que la prestación sea efectiva.
Así, este ciclo desarrolla una función transversal para todos los otros procesos de TI,
pero sin afectar a la realización del flujo de trabajo diario. Se encarga de articular y
Contenidos de un contrato de soporte (UC)
Contrato redactado en términos contractuales

3 Alcance del contrato.
3 Horarios y niveles de servicio.
3 Condiciones comerciales.
3 Penalizaciones.
3 Responsabilidades y dependencias.
3 Procedimientos de revisión y seguimiento
del contrato.
3 Gestión de conflictos.
3 Requisitos para la etapa de transición.
3 Etapa de finalización del contrato. Obligaciones.
3 Confidencialidad y derechos de propiedad
intelectual.
3 Anexos:
• Inventarios base (baseline).
• Contenido completo del RFP.
Figura 7.3.21. Contenido tipo de los contratos de soporte (UC)
desplegar lo necesario para que este flujo sea efectivo: reuniones, interlocutores,
herramientas, interfaces, procedimientos, escalados, etc. Por tanto, éste es un ciclo o
subproceso que prepara los “conectores” entre la organización de TI y sus suminis-
tradores, para supervisar posteriormente su funcionamiento.
En las Normas ISO/IEC 20000 se establecen unos requisitos muy básicos para la
gestión de la prestación del servicio del suministrador:
UNE-ISO/IEC 20000-1
Se debe monitorizar y revisar el comportamiento y las prestaciones frente a los

objetivos de nivel de servicio. Las acciones de mejora identificadas durante este
proceso se deben registrar y utilizar como información de entrada al plan de
mejora del servicio.
UNE-ISO/IEC 20000-2
Definición del servicio c) un proceso de gestión de contra-

tos, los niveles de autorización y
Para cada servicio y suministrador el pro- un plan de extinción del contrato;
veedor del servicio debería mantener:
d) las condiciones de pago, si son
a) una definición de servicios, roles y relevantes;
responsabilidades;
e) los parámetros de informe y el re-
b) el alcance del servicio; gistro acordados sobre el desem-
peño alcanzado.
Como se ha mencionado anteriormente, hay grandes diferencias entre la importan-

cia y los alcances entre los diferentes contratos. Por ello, la gestión de los suminis-
tradores se llevará con más o menos intensidad, adecuándose al tipo y la relevancia
de la función contratada en cada uno de ellos (resultado de la categorización de
suministradores y contratos de la actividad anterior).
Los principales mecanismos que articula este ciclo, necesarios para que sea efectivo
el flujo entre la organización de TI y las organizaciones de los suministradores son
los siguientes:
Escalados. Al igual que en el caso del proceso de gestión del incidente, aquí tam-
bién existe el concepto de escalado, en sus dos versiones, funcional y jerárquica. El
escalado funcional corresponde al traspaso de trabajos entre los grupos funcionales,
bien entre la organización de TI y los suministradores o bien entre ellos mismos.
En el escalado jerárquico se remite información hacia instancias superiores, para
poner en conocimiento o para la toma de decisiones. El escalado jerárquico tam-
bién es la primera etapa en la resolución de discrepancias y conflictos en la relación.
En ambos casos, las rutas de escalado deben estar previamente definidas y procedi-
mentadas.
Herramientas. Definición e implementación de las herramientas para el soporte
del flujo de trabajo. Las diversas soluciones de integración entre las herramientas
pueden ir desde permitir el acceso del suministrador a las herramientas internas de
TI, hasta una interconexión entre las herramientas de ambas organizaciones.
Informes. Información periódica sobre la actividad y desempeño del suministra-
dor en relación a los servicios contratados. Los informes contienen información
cuantitativa (indicadores o métricas) sobre volumetrías de los trabajos, sobre la
calidad de los mismos y sobre los niveles de los servicios prestados. Además, los
informes incorporan información descriptiva de la actividad realizada en el período
y del grado de avance de proyectos y trabajos de plazo más largo.
Interfaces. Como parte de la definición de las herramientas, aparecen las interfaces

para el traspaso de trabajos e información entre la organización de TI y del sumi-
nistrador. Las interfaces pueden ser automatizadas, interconexionando las herra-
mientas (traspaso de tickets de incidentes, de ordenes de trabajo, información de
configuración, etc.), semiautomáticas (por ejemplo, a través del correo electró-
nico), o manuales (por ejemplo, el contacto por teléfono). Según el volumen del
flujo que se gestionará se decidirá la interfaz más adecuada a cada caso.
Interlocución. Definición de los niveles de interlocución entre las personas de
ambas organizaciones. Definición de los roles de interlocución y la designación for-
mal de las personas que desempeñarán estas funciones. Se deben definir los puntos
de contacto (touch points) entre ambas organizaciones y las funciones que desempe-
ñará cada uno de ellos.
Monitorización del desempeño. Seguimiento continuo de los principales indica-
dores definidos para el control de la prestación del servicio contratado.
Procedimientos. Definición del procedimiento para la gestión del flujo de trabajo
entre ambas organizaciones, junto a la definición de cómo fluirán todos los proce-
sos de gestión del servicio (incidente, cambio, entrega, etc.) entre ambas organiza-
ciones. La estandarización de los procesos de TI, proporcionada por la amplia
aceptación de ITIL en el mercado, hace mucho más sencilla la extensión de un pro-
ceso (por ejemplo, la gestión del incidente) entre la organización de TI y los sumi-
nistradores. Además, puestos en la perspectiva de un suministrador que presta ser-
vicio a múltiples organizaciones de TI clientes, ITIL les permite mantener unos
procesos únicos que enganchan perfectamente con los procesos de sus clientes.
Programa de mejora del suministrador (SIP). Las acciones de mejora identifica-
das se incorporan en un plan de mejora con cada suministrador. Al igual que en la
gestión de nivel de servicio (véase el apartado 6.1), a estos planes de mejora de
los servicios proporcionados por el suministrador también se les denominan SIP
(Service Improvement Program), y se coordinan de forma conjunta en el Plan de
mejora unificado de los procesos y de los servicios (véase el capítulo 4).
Reuniones. Establecimiento de las reuniones como instrumentos de supervisión,
decisión y reporte. En los contratos de prestación de servicios continuos de una
cierta importancia, las reuniones se suelen estructurar en tres niveles:
• Comité ejecutivo del contrato. Órgano máximo de decisión. Se suele reu-
nir con carácter trimestral. En contratos muy grandes, también se suele ins-
trumentar un comité de seguimiento económico.
• Comité de seguimiento del servicio. Grupo mixto en el que se sigue men-
sualmente la evolución del servicio, del cumplimiento de los niveles de servi-
cio contratado y de los principales trabajos.
• Grupos de trabajo. Equipos de trabajo especializados en una temática o

actividad específica. Creados ad hoc para resolver una problemática determi-
nada o de forma permanente (de tecnología, de arquitectura, etc.).
Revisiones del servicio. Análisis y reuniones periódicas realizadas para comprobar

el cumplimiento de compromisos y la identificación de acciones de mejora por
ambas partes.
Una vez identificados estos mecanismos anteriores, necesarios para que el flujo de
información y trabajo entre ambas organizaciones sea eficaz, se debe definir el con-
junto de actividades principales que componen este ciclo de prestación (para ello,
se ha considerado importante seguir la definición de ITIL v3). En la figura 7.3.22
se muestran las principales actividades de este ciclo.

Finalización
Actividades gestión de la prestación
• Gestión y control de la operación y del suministro de productos y servicios.

• Monitorización y generación de informes.
• Revisiones y mejora.
• Gestión del suministrador y de la relación.
• Revisión periódica de los objetivos del servicio frente a las necesidades del
negocio, objetivos y acuerdos.
• Planificación para posible cierre, renovación o extensión.
Figura 7.3.22. Principales actividades de la gestión de la prestación

de los suministradores
Gestión y control de la operación y del suministro de productos y servicios. La

prestación de los servicios, y en general las actividades del día a día implican la parti-
cipación de dos organizaciones diferentes, que en la mayoría de los casos cuentan
con procesos operacionales diferentes. El foco de esta actividad es garantizar la reali-
zación eficiente de las mencionadas actividades del día a día. Para ello revisa los atas-
cos y los retrasos en las peticiones y órdenes de trabajo diarias, controla la calidad de
los productos o servicios recibidos, integra los servicios recibidos de los suministra-
dores con los servicios de TI ofrecidos a las áreas cliente, y supervisa de forma conti-
nua el funcionamiento de las herramientas y las interfaces para garantizar que el tra-
bajo fluye con normalidad.
Para asegurar una correcta relación con los suministradores es fundamental el esta-
blecimiento de conductos de comunicación eficientes, que permitan a ambas partes
profundizar en su conocimiento mutuo. De esta forma, la interrelación para la
prestación diaria de los suministradores se suele articular en base a tres tipos de uni-
dades de información que fluyen hacia los suministradores:
• Tickets. Traspaso de tickets de incidentes y peticiones de servicio recogidas
en el catálogo de servicios, que normalmente provienen directamente del
contacto con el usuario.
• Órdenes de trabajo. Envío de órdenes de trabajo o peticiones, que son
generadas por la organización de TI para solicitar trabajos al suministrador
(cambios, informes, actuaciones, etc.).
• Proyectos. Actividades de mayor envergadura y complejidad que suelen
contener unos objetivos, una planificación, unos compromisos, una direc-
ción específica, un presupuesto determinado, etc. Los proyectos pueden ser
de todo tipo: de desarrollo de software, de arquitectura, de diseño, de plata-
forma tecnológica, etc.
Dependiendo del nivel de externalización o del alcance de cada contrato, la gestión

de la prestación varía mucho. En contratos de adquisición de hardware o productos
software, termina una vez entregado e instalado el producto la prestación del sumi-
nistrador. Los contratos de mantenimiento tienen algo más de penetración en la
actividad diaria (incluyendo la garantía). En los contratos de soporte técnico de los
fabricantes sólo se activan en casos esporádicos de necesidad ante averías o proble-
mas técnicos con sus plataformas. En el extremo opuesto de intensidad en la inter-
acción con el día a día aparecen los contratos de externalización de un servicio o de
una función de TI. En ellos, los flujos de trabajo son constantes entre la organiza-
ción de TI y los diversos suministradores.
Así, dependiendo del perfil de externalización y del número de suministradores,
varía bastante el flujo diario de la actividad que cruza las fronteras de las organiza-
ciones. En todo momento, y a efectos puros de certificación bajo las Normas
ISO/IEC 20000, es necesario mantener el control de su gestión.
Hay que tener cuidado en que la gestión de la operación del suministrador no se
interponga entre las áreas operativas de ambas partes, sino que supervise el flujo
desde el exterior, para detectar atascos y malos rendimientos.
Monitorización y generación de informes (del servicio, calidad y costes). Se realiza

el seguimiento de la actividad y de los resultados mediante indicadores sobre la pres-
tación de servicios y sobre la entrega de productos. La misión principal es contrastar
que los niveles de servicio recibidos cumplen lo requerido en el contrato. Por tanto, la
monitorización tiene el objetivo de comprobar que el suministrador cumple con
lo pactado. Si en el contrato se contempla una tarifa variable o unas penalizaciones en
función de unos indicadores, la monitorización es el instrumento de medición.
También se generan los informes periódicos definidos asociados al seguimiento del
servicio y del suministrador. La periodicidad de los informes con los suministrado-
res se marca según la importancia de los servicios contratados, y siempre alineados
con los informes más globales del servicio de TI. En su amplitud máxima los infor-
mes comprenden:
• Semanal. En los informes semanales se realiza el seguimiento y control de la
actividad del suministrador en la semana, normalmente el avance de proyec-
tos críticos, volumetrías de resolución y los principales eventos de la semana.
• Mensual. Recoge un cierre del mes, con los principales indicadores, avance
de los proyectos e hitos globales del suministrador.
• Trimestral. Recoge un seguimiento de aquellos ratios anuales sobre los que
conviene realizar un seguimiento más de cerca de cara a emprender acciones
correctoras en caso de desviaciones negativas.
• Anual. Refleja los principales parámetros del suministrador y su contribu-
ción a los indicadores generales de TI. Normalmente se contemplan: varios
ratios de coste medio, métricas de volúmenes de trabajo (medido por usua-
rio), cumplimientos de plazos, cumplimientos de objetivos, etc. Se utilizan
para medir el logro de los macroobjetivos definidos en la estrategia del año
bajo consideración (en curso o cerrado y objeto de revisión) y para definir la
nueva estrategia.
Revisiones y mejora (del servicio, calidad y costes). De forma periódica se debe

realizar un análisis del desempeño del suministrador, contemplando tanto la canti-
dad de servicios y productos entregados, como los niveles de servicio, plazos, cali-
dad y los costes. Con estas revisiones, consensuadas entre ambas partes, se identifi-
can diversas acciones de mejora y se crea un programa de mejora del servicio
prestado (SIP) por el suministrador. En las revisiones se debe comprobar no sólo
el servicio en sí mismo, sino cómo contribuye en la cadena de aseguramiento del
servicio final de TI hacia los clientes.
En las revisiones se debe poner foco también en aprender de las mejores prácticas
del suministrador para evitar imponerle prácticas menos efectivas.
Gestión del suministrador y de la relación. Comprende la gestión de las relacio-

nes, de los contratos y de las discrepancias surgidas. Atiende los escalados verticales
por discrepancias, y mantiene los contactos a nivel de gestión y de dirección por
ambas partes. Se suele realizar en el ámbito del comité de seguimiento del servicio.
En esta actividad se marca una pauta de reuniones periódicas (quincenales o mensua-
les) de este comité. En la gestión de discrepancias es importante la resolución tem-
prana de conflictos, para que éstos no afecten al servicio o contaminen la relación.
Con respecto a la gestión de contrato en vigencia se realiza:
• El seguimiento del cumplimiento de los términos y condiciones del contrato.
• La revisión de las facturas.
• La aprobación de los pagos.
• La negociación de las revisiones del contrato.
• La gestión de los cambios al contrato (vía proceso de gestión del cambio).
El entendimiento de la cultura de ambas organizaciones y de la forma de trabajar

de cada una de ellas, permitirá un planteamiento de la relación más acorde con la
realidad y proporcionará unos mejores resultados a ambas partes por el adecuado
entendimiento de necesidades y capacidades (gestión de expectativas). También se
debe poner foco en que las vías de comunicación fluyan y, sobre todo, que los nive-
les directivos estén disponibles y dediquen el tiempo necesario para la toma de
decisiones en el momento adecuado.
A este respecto las especificaciones de las Normas ISO/IEC 20000 aportan una for-
malización a la relación contractual:
UNE-ISO/IEC 20000-1
Los cambios al contrato(s), si existen, y los SLAs deben ser el resultado de estas revi-
siones o de aquellas requeridas en cualquier otro momento. Cualquier cambio debe
estar sujeto al proceso de gestión del cambio.
UNE-ISO/IEC 20000-2
Gestión de contratos todo un grupo de personal involucrado

en esta tarea, debería existir un proceso
El proveedor del servicio debería desig- común para asegurar que la información
nar un responsable para hacerse cargo sobre el desempeño de los suministrado-
de los contratos y acuerdos con los res está controlada y se actúa conse-
suministradores. En el caso de que haya cuentemente.
Debería existir una persona de contacto El proceso para la modificación de con-

definida dentro de la organización del tratos debería estar también claramente
proveedor del servicio que sea el res- definido. Cualquier cambio a este proce-
ponsable de la relación con cada sumi- dimiento se debería notificar formalmente
nistrador. a todos los suministradores afectados.
Todos los contratos con suministradores Se debería mantener una lista de puntos
deberían contener una planificación de de contacto dentro de las respectivas
las revisiones para evaluar si los objeti- organizaciones (la del suministrador y la
vos de negocio para el suministro de un del proveedor del servicio). Si un contrato
servicio siguen siendo válidos. incluye penalizaciones o bonificaciones,
Debería existir un proceso claramente se deberían establecer claramente sus
definido para la gestión de cada con- fundamentos y elaborar un informe del
trato. cumplimiento de los requisitos.
Revisión periódica de los objetivos del servicio frente a las necesidades del
negocio, objetivos y acuerdos. Se suele realizar en el ámbito del comité ejecutivo.
Se identifican los puntos conflictivos, el desempeño de los interlocutores y se rea-
liza la revisión de todos los indicadores comprometidos. Su periodicidad suele ser
trimestral, con los suministradores esenciales, y anual con el resto. También se
deben replantear si los objetivos contratados están alineados con las necesidades
de TI y del negocio.
En este ámbito se llevan a cabo dos tipos de revisiones formales: la revisión del
desempeño del suministrador (en base a revisiones del servicio) y la revisión del con-
trato (del rendimiento, de los escalados, los costes, las variaciones en la demanda, las
mejoras al servicio, la opinión de los clientes, etc.).
Planificación para posible cierre, renovación o extensión. Toda la actividad dia-
ria debe estar concebida para que se retenga el conocimiento, de esta forma, la
dependencia de un suministrador determinado es menor. Además de esto, con la
anticipación necesaria (normalmente 3 meses antes) se debe decidir si se continuará
con el servicio, se procederá a su renovación y en qué ámbitos se modificará su
alcance. En función de la decisión tomada, se iniciarán las acciones de recopilación
de información, auditorías necesarias, denuncia del contrato, etc.
Etapa de finalización del contrato

La etapa de finalización del contrato está también reglada en ISO/IEC 20000, en
el que se requiere que exista un procedimiento para la finalización de un servicio
contratado, bien sea por que se alcance la fecha de término del contrato (terminación
normal) o de forma anticipada. También se debe contemplar la transferencia a un

tercero o la reabsorción por parte de la organización de TI.
UNE-ISO/IEC 20000-1
Debe existir un proceso para gestionar la finalización normal o anticipada de un

servicio, o la transferencia del mismo a un tercero.
UNE-ISO/IEC 20000-2
El proceso de gestión de contratos debe- También debería proporcionar un meca-

ría contemplar la extinción del contrato nismo de transferencia del servicio a otra
(tanto planificada, como prematura). organización.
Conviene aclarar que este proceso de gestión de contratos, mencionado en

ISO/IEC 20000-2, forma parte del proceso de gestión de suministradores, pues es
uno de los requisitos especificados en ISO/IEC 20000-1, aunque no se le da el
nombre formal de “gestión de contratos”.
Las principales actividades de la etapa de finalización del contrato se muestran en
la figura 7.3.23.

Finalización
Actividades de finalización del contrato
• La revisión del contrato.

• La renegociación o cierre del contrato.
Figura 7.3.23. Principales actividades de la fase de finalización del contrato
Llegada la fecha en la que el contrato finaliza, se deben realizar dos acciones princi-
pales (según ITIL v3).
La revisión del contrato. Antes de la finalización del contrato se debe realizar un

análisis y revisión de los resultados obtenidos y del transcurso del contrato. Esta
revisión se realiza desde una visión más alejada de las turbulencias del día a día, con
la perspectiva de la distancia, para poder tener una valoración justa de los resulta-
dos obtenidos y poder recomendar las acciones para las nuevas contrataciones.
La renegociación o cierre del contrato. Si se ha decidido continuar el contrato se ini-
cia una nueva fase de contratación, entrándose de nuevo en el ciclo de selección y con-
tratación. Si la decisión es de finalización o terminación del contrato, se deben activar
las cláusulas de expiración. Como se ha debido planificar previamente la finalización del
mismo, la ejecución del cierre será más sencilla. En las cláusulas de cierre, se habrá con-
templado el período de transición del saliente hacia el nuevo entrante o hacia la propia
organización (reabsorción del servicio). Normalmente este coste de transición se
imputa al contrato entrante, salvo que la finalización sea por causas achacables al sumi-
nistrador saliente, en cuyo caso y en función de lo especificado en las cláusulas de pena-
lización, podrá ser imputado a dicha organización. La identificación de personal clave y
una transferencia de conocimientos documentada, planificada y auditada son esenciales.
Gestión de los conflictos contractuales

La gestión de conflictos de carácter contractual también se trata en las Normas
ISO/IEC 20000, especificándose en la parte 1 que debe estar procedimentada la
gestión de los desacuerdos contractuales, y en la parte 2 recomendándose que se
incluya el procedimiento en el contrato y que los conflictos se registren, se investi-
guen, se resuelvan y se cierren formalmente.
UNE-ISO/IEC 20000-1
Debe existir un proceso para tratar los desacuerdos contractuales.
UNE-ISO/IEC 20000-2
Tanto el proveedor del servicio como el que no puedan ser resueltos mediante
suministrador deberían funcionar con- el procedimiento ordinario.
forme a un proceso para gestionar los El proceso debería asegurar que los
conflictos, el cual se debería definir o conflictos son registrados, investigados,
referenciar dentro del contrato. que se toman las acciones necesarias
Debería existir un procedimiento o itine- sobre ellos y que se cierran formal-
rario para poder escalar los conflictos mente.
La mejora continua del proceso

Al igual que en el resto de los procesos de gestión de TI en ISO/IEC 20000, la ges-
tión de suministradores debe tener una actividad de autorrevisión del propio pro-
ceso, analizando cómo está funcionando el proceso, si está siendo positivo para la
organización, si se cumplen los objetivos definidos, etc. Como resultado, se pro-
duce un programa de mejora del proceso que se debe coordinar con el resto de los
procesos a través del Plan de mejora unificado de los procesos y de los servicios
(véase el capítulo 4); ya que ningún proceso debe cambiarse a sí mismo sin estar
en coordinación con los demás.
Gestión de múltiples suministradores

En ISO/IEC 20000-2 se establecen algunas recomendaciones para el caso de que
se encargue a un suministrador principal la gestión del resto de los suministradores
para la prestación del servicio.
UNE-ISO/IEC 20000-2
Debería quedar claro si el proveedor del ción del proveedor del servicio si así lo
servicio trata con todos los suministradores requiere.
de forma directa o mediante un suministra-
El proveedor del servicio debería obtener
dor principal que toma la responsabilidad
evidencias de que los suministradores
de los suministradores subcontratados.
principales gestionan formalmente a los
El suministrador principal debería regis- suministradores subcontratados; guián-
trar los nombres, responsabilidades y dose, cuando sea apropiado, por los
relaciones entre todos los suministrado- requisitos incluidos en la Norma ISO/IEC
res subcontratados y ponerla a disposi- 20000-1.
Ésta es una situación frecuente en grandes externalizaciones, en las que se quiere

alcanzar una madurez en la gestión del servicio, y que para ello se recurre a una
empresa especializada en la gestión de servicios que se encarga únicamente de los
procesos y herramientas de gestión, mientras que se contrata a otros suministrado-
res la provisión de servicios más especializada.
Otro caso frecuente es la concentración de contratos de mantenimiento del hard-
ware a una única empresa.

Las métricas asociadas al proceso miden el cumplimiento de lo contratado por
parte del suministrador, junto con el comportamiento concreto del proceso. Para
que las métricas asociadas a la prestación del servicio por parte del suministrador
puedan tener el respaldo contractual, es necesario que se definan las mismas con
carácter previo al establecimiento del contrato, o bien que se establezca su defini-
ción en la etapa de transición.
Las métricas dependen del tipo de producto o servicio contratado, ya que no es
lo mismo la compra de equipamiento hardware, que la prestación continua de un
servicio de telecomunicaciones.
Para el caso de prestación de servicios de externalización, las métricas serían las mis-
mas que las definidas para cada uno de los procesos. De forma general, las métricas
aportarán información sobre el cumplimiento de lo contratado, en relación a los
niveles de servicio, los plazos de ejecución, los volúmenes de trabajo, los costes, la
calidad, etc.
Al tratarse también de una relación entre dos organizaciones, también se podrá
medir el funcionamiento de la relación entre la organización de TI y el suministra-
dor, para determinar si es de fluida, eficiente y satisfactoria. Por otra parte, las
métricas recogerán información sobre la satisfacción de la organización de TI con
los servicios del suministrador.
Los indicadores que se enumeran a continuación son de ámbito genérico con inde-
pendencia del servicio contratado.
• Valoración de la calidad global del suministrador y de sus servicios, en base a
encuestas de satisfacción de las áreas internas que reciben los servicios.
• La disponibilidad total y de cada uno de los servicios durante el horario
comprometido de los mismos.
• Cumplimiento de plazos medios de ejecución de peticiones de los usuarios.
• Cumplimiento de plazos medios de ejecución de peticiones u órdenes de tra-
bajo de la organización de TI al suministrador.
• Cumplimiento de plazos y calidad de los proyectos
• El grado de cumplimiento de otros aspectos de los acuerdos del nivel de ser-
vicio en cuanto a calidad, horario, tiempos de atención, etc.
• Volumen de actividad realizada en el período.
• El coste medio por unidad de servicio o por unidad de capacidad.
• La calidad de la información registrada, evaluada por revisiones o auditorías

internas.
• Número de escalados horizontales medios por petición o trabajo, que miden
la eficacia en la actividad diaria.
• Número de conflictos surgidos.
• Etc.
En la figura 7.3.24 se muestra un resumen de los indicadores más relevantes para

este proceso.
Figura 7.3.24. Ejemplo de métricas para este proceso

Los roles que participan se estructuran en los roles propios del proceso y los roles
ajenos al proceso (el gestor del nivel de servicio).
En este caso, dada la diferencia tan importante entre las actividades de estrategia de
sourcing, el ciclo de selección y contratación, y el ciclo de gestión de la prestación,
se suelen establecer roles específicos para cada una de estas etapas del proceso. En
empresas de tamaño medio muchos de estos roles se suelen agrupar en una única
persona.

• El responsable de la estrategia de sourcing o responsable de la oficina de sour-
cing (CSO, Chief Sourcing Officer), que define y vela por la implementación
de la estrategia de sourcing.
• En la estrategia de sourcing:
– El gestor de contratos. Que se encarga de la gestión formal y contractual
de todos los contratos firmados en curso.
• En el ciclo de selección y contratación:

– El responsable de compras. Responsable de la ejecución de la política de
selección y contratación de productos y servicios.
– El comprador. Lleva a cabo la ejecución de la selección y contratación de
productos y servicios.
• En el ciclo de gestión de la prestación:

– El gestor de las relaciones con el suministrador (gestor del proceso o pro-
cess manager), que es el responsable máximo del proceso y del cumpli-
miento de los objetivos del mismo. Se encarga del funcionamiento del
proceso en detalle, de subsanar las deficiencias, de resolver conflictos, etc.
– Los gestores de suministradores, que desempeñan una función operativa
de supervisar día a día la relación con el suministrador. Lidera las reunio-
nes con el suministrador, supervisa el cumplimiento de los procedimien-
tos y el correcto funcionamiento del día a día.
– Los administradores o personal de soporte al proceso, personal que con-
tribuye en organizar la actividad, realizar encuestas de satisfacción, reali-
zar informes, apoyo a los gestores de cliente, etc.
Los roles ajenos que son relevantes en este proceso son los siguientes.
cumplan los niveles pactados. Aporta los niveles de servicio a mantener en
los contratos.
• Las áreas de TI proponentes de las compras, que son las que solicitan la rea-
lización de las compras.
• El responsable de informes, aportando los informes que se deben entregar al
cliente.
Los roles de mayor relevancia que participan en el proceso de gestión de suminis-

tradores se representan en la figura 7.3.25.
Roles del proceso
Estrategia Selección y
Prestación
de sourcing contratación
Responsable de la
Chief Sourcing Responsable Gestor de las
SGSTI Officer de compras relaciones con
el suministrador
Propietario del
modelo (SGSTI)
Administrador y
soporte del proceso
Gestor de
suministradores
Gestores del Áreas de TI proponentes
nivel de servicio de las compras
Figura 7.3.25. Roles del proceso de gestión de suministradores
Resumen
La maduración del sector lleva paulatinamente hacia la concentración de “la fábrica
de los servicios de TI” en empresas especializadas que prestan servicios al resto de
organizaciones internas de TI. Lo que permite que las empresas se centren en las
actividades que aporten un valor diferencial a su negocio, recurriendo a la exter-
nalización de las funciones no esenciales que el mercado comercializa empaque-
tadas en forma de producto o servicio (ERP, mantenimiento correctivo de soft-
ware, comunicaciones, hosting, monitorización, operación, atención telefónica al
usuario, etc.).
Como consecuencia, cada vez se externalizan más actividades de la organización de
TI. Por ello, la gestión de los suministradores, casi inexistente hasta, ahora se ha
convertido en un proceso clave para el éxito en los servicios de TI.
La gestión de suministradores también debe tener en cuenta que detrás de un sumi-
nistrador hay personas, que además de ser eficientes en el cumplimiento de sus
compromisos, tienen sentimientos, vida personal, familia, frustraciones, etc.
De forma histórica las grandes organizaciones han desarrollado el ciclo de selección
y contratación de suministradores, implementando buenas prácticas y políticas en
la selección y en la contratación. En cambio, el ciclo de gestión de la prestación del
suministrador es apenas un recién nacido, pero esencial en un escenario con cada
vez más funciones de TI externalizadas.
Los aspectos más destacados de este proceso son los siguientes:
• El proceso de gestión de suministradores abarca todo tipo de servicios, desde
la compra de productos, pasando por la contratación de servicios, hasta los
diversos tipos de externalizaciones.
• La estrategia de sourcing define las actividades que se realizarán interna-
mente y las que se contratarán a los suministradores. Una vez definida, la
implementación de esta estrategia pasa por el establecimiento de acuerdos
marcos de tarifas con los suministradores principales, que promocionen más
agilidad para las contrataciones del día a día y faciliten la tendencia hacia una
consolidación de suministradores.
• El proceso, bajo aproximación pura ISO/IEC 20000, partiría de una estrate-
gia de sourcing ya definida para dividirse en dos grandes ciclos, junto con una
actividad de finalización del contrato:
– El ciclo de selección y contratación de productos y servicios.
– El ciclo de gestión de la prestación de los suministradores.
• Dado su carácter contractual, este proceso requiere mayor formalización que

otros, desde la designación de los representantes hasta un seguimiento por
escrito de la actividad (actas).
• El ciclo de seguimiento de la prestación es bastante nuevo en las áreas de TI,

por lo que es una disciplina en pleno desarrollo que irá madurando y espe-
cializándose según los tipos de servicios que se contraten.
• La definición de los mecanismos de relación y seguimiento de la prestación
resulta esencial, comprendiendo comités, dinámica de reuniones, informes
de seguimiento, interlocutores, interconexión de los flujos de trabajo, inter-
faces entre herramientas, etc. Por ello, es necesaria la definición clara de las
funciones de los roles de interlocución de las organizaciones participantes.
• Las interfaces entre las herramientas de gestión en toda la cadena de sumi-
nistradores son esenciales para la eficacia de los diversos flujos de trabajo:
incidentes, peticiones, órdenes de trabajo, etc.
• El proceso recopila todo el conocimiento de la relación en la base de datos
de suministradores y contratos (SCD).
• El ciclo de seguimiento de la prestación no debe ser tan denso que estran-
gule la fluidez necesaria en la actividad del suministrador.
Estamos asistiendo a la transformación de la actividad de TI externalizando cada

vez más funciones, en búsqueda de la eficiencia en costes, la calidad y la agilidad.
En esta evolución es esencial velar también por el cambio cultural de la organiza-
ción. Se debe considerar que con frecuencia, las restricciones propias impuestas por
la organización contratante o el incumplimiento por alguno de sus miembros de
sus responsabilidades, puede perjudicar gravemente los resultados de la prestación
del suministrador. Por ello, este proceso debe mirar también hacia el interior de su
organización, para limar imposiciones no necesarias, para supervisar el desempeño
de la organización retenida y para velar por la adaptación progresiva de la organi-
zación a la nueva realidad en TI.
Beneficios
La gestión de suministradores permite garantizar que las necesidades de la organi-
zación de TI se aprovisionan de forma alineada con la estrategia general, y que los
productos y servicios contratados cumplen con los acuerdos firmados. Entre los
beneficios obtenidos destacan:
• Definición de una estrategia de sourcing, que identifica las actividades críticas
a retener y las funciones que se externalizarán.
• Se asegura la ejecución de la estrategia de sourcing en lo relativo a la contra-
tación externa.
• Da rigor y transparencia a las actividades de contratación de productos y ser-

vicios.
• Obtiene importantes ahorros por una gestión de las compras coordinada y
homogeneizada.
• Implementa una sistemática para que la relación y gestión de los suministra-
dores se realicen de forma homogénea por todas las unidades.
• Implementa las mejores prácticas en la gestión de los suministradores.
• Alinea las necesidades de la organización de TI con los servicios contratados.
• Se almacena el conocimiento sobre los suministradores y su desempeño.
• Según su opinión, ¿qué debe contemplar la estrategia de sourcing de TI?
• ¿Cómo se realizan la selección y contratación de suministradores en su
organización?
• Según su experiencia, ¿qué aspectos destacaría en la gestión de los sumi-
nistradores?
8 Procesos de
resolución
Capítulo 8
8.1. Antecedentes
8.2. Gestión del incidente
8.3. Gestión del problema


8. Procesos de resolución 537
Los procesos de resolución gestionan el alto volumen de incidentes y peticiones de

usuario que se generan en torno a los servicios de TI. También incluyen las accio-
nes necesarias para ir mejorando los defectos en los sistemas y las infraestructuras
que soportan los servicios.
El proceso de gestión del incidente pretende restaurar los servicios a su funciona-
miento normal de la forma más rápida posible.
Además, la gestión del incidente también incluye la gestión de la petición, enten-
diéndose como tal las solicitudes de servicio de los usuarios previstas en el catálogo
de servicios.
Los incidentes y las peticiones generan cada uno de ellos un flujo de actividad que
recorre gran parte de los equipos de soporte de TI. Suponen una importante carga
de actividad en TI, por ello, se debe poner énfasis su automatización y en optimi-
zar su tratamiento en busca de cuotas altas de eficiencia.
Para mejorar la calidad de los servicios y reducir la frecuencia de aparición de inci-
dentes, aparece el concepto de problema. En este ámbito de TI, el término pro-
blema tiene un significado algo diferente al uso cotidiano: es todo defecto subya-
cente en los servicios que genera o puede generar incidentes.
La gestión del problema tiene como objetivo identificar y eliminar los defectos y
fallos en los servicios. Con ello, se consigue reducir en número de percances en los
mismos, mejorar la calidad ofrecida al negocio y reducir la actividad de soporte.
En este capítulo se presentan las directrices, mejores prácticas y recomendaciones
para la gestión de los incidentes, así como, la mejor forma de abordar la tarea analí-
tica y de investigación que es la resolución de los problemas.
8. Procesos de resolución
8.1. Antecedentes 539
8.1. Antecedentes
Figura 8.1.1. Relaciones entre los procesos de resolución
La gestión del incidente se centra en restaurar el servicio cuanto antes, sin admitir
dilaciones por investigaciones técnicas. Su objetivo es que todo servicio caído o
degradado retorne cuanto antes a la normalidad.
Mantener únicamente esta actividad frenética de “apaga fuegos” no sería produc-
tivo, pues los defectos no reparados producirían más y más incidentes. Así, de
forma independiente, se debe realizar una labor más sosegada y concienzuda
de análisis de los fallos, para buscar soluciones definitivas. Aquí aparece la necesi-
dad de un nuevo proceso como la gestión del problema.
Las Normas ISO/IEC 20000 dedican unos párrafos introductorios a los procesos
de resolución, estableciendo una relación permanente entre ambos procesos, defi-
niendo el concepto de prioridad e introduciendo las soluciones provisionales:
UNE-ISO/IEC 20000-1
Antecedentes
La gestión del incidente y la gestión del problema son procesos separados, aunque
ambos están fuertemente relacionados.
UNE-ISO/IEC 20000-2
La gestión del incidente y del problema mientras la gestión del problema tiene
son procesos distintos, aunque están como misión la identificación y la elimi-
estrechamente relacionados. El proceso nación de las causas de los incidentes.
de gestión del incidente se encarga de la
restauración del servicio a los usuarios,
La relación entre ambos procesos es constante, pues la gestión del incidente genera
información que posteriormente analizará la gestión del problema en busca de
defectos en los servicios. Así, en su actividad diaria de restaurar el servicio, la ges-
tión de incidente se encuentra frecuentemente con defectos en los servicios. Como
su función no es dedicarse a erradicarlos, los comunicará a la gestión del problema
para a su análisis y resolución. Por otra parte, la gestión del problema vuelca su
conocimiento y las soluciones encontradas en una base de datos, para que la ges-
tión del incidente los pueda aplicar en futuros incidentes similares.
Prioridad de un incidente y de un problema

Puesto que en una organización media de TI se gestiona un volumen alto de inci-
dentes, es necesario definir, en la actividad de clasificación, la prioridad con la que
se debe tratar este incidente. Igualmente ocurre a la hora de asignar un orden de
resolución a una lista de problemas abiertos. ISO/IEC 20000-2 recomienda calcu-
lar la prioridad como resultado de dos aspectos: la urgencia y el impacto en la orga-
nización.
UNE-ISO/IEC 20000-2
Los objetivos para la resolución debe- La planificación de la resolución de inci-

rían estar basados en la prioridad. La dentes o problemas debería tener en
prioridad se debería basar en el cuenta, como mínimo, lo siguiente:
impacto y la urgencia. El impacto se a) la prioridad;
debería basar en el nivel de daño real
b) las habilidades disponibles;
o potencial al negocio del cliente. La
urgencia se debería basar en el tiempo c) los requisitos de competencia para
entre la detección del problema o del los recursos;
incidente y el momento en que se pro- d) el esfuerzo/coste necesario para
duce el impacto sobre el negocio del proporcionar el método de reso-
cliente. lución;
e) el tiempo transcurrido para pro- Nota: La prioridad se utiliza durante toda la ges-
porcionar un método de resolu- tión del servicio pero es fundamental para la ges-
tión del incidente y del problema.
ción.
Estas dos variables independientes condicionan el nivel de prioridad de un inci-

dente y la rapidez con la que se va a tratar de resolverlo:
• El impacto: medida del efecto sobre el negocio que actualmente tiene un
incidente o que potencialmente podría tener. Se relaciona con el grado en
que se podría llegar al incumplimiento de los SLA. Se puede valorar en fun-
ción de la criticidad para el negocio del servicio afectado, del número de
usuarios perjudicados y de su importancia para la organización. El impacto
se suele medir en 3 niveles; alto, medio y bajo.
• La urgencia: medida de la criticidad en cuanto al plazo de resolución de un
incidente en función de las fechas límites para su resolución. Se asocia con el
tiempo disponible para la resolución antes de que se llegue al incumpli-
miento de los SLA. La prioridad se puede medir en 3 niveles: alta, media y
baja. También es frecuente asignarla a metales: platino, oro, plata y bronce.
Esta misma clasificación de impacto y urgencia se utiliza para ordenar por priori-
dad los cambios (véase también el apartado 9.2).
En cualquier caso, los criterios para definir el impacto y la urgencia deberían esta-
blecerse en coordinación con los responsables del negocio y formalizarse en el SLA.
En la figura 8.1.2 se presentan los tipos de prioridad más habituales y un rango
orientativo del tiempo de atención asociado.
Tiempo
Prioridad Descripción
atención
Se necesita una acción inmediata. Se identifica como

incidente grave.
Inmediata En minutos
Puede ser necesario asignar recursos inmediatamente y
activar el procedimiento de crisis.
Alta Tienen preferencia de atención. <1 hora
Será asignada una prioridad media en cuanto a la

Media <2 horas
dedicación de recursos.
La resolución del incidente puede esperar.
Baja <6 horas
Serán asignados recursos en cuanto queden libres.
Figura 8.1.2. Ejemplo de tipificación de prioridades de un incidente

Los incidentes de prioridad inmediata suelen tener la consideración de incidente

grave y tienen un tratamiento predefinido. Cuando se prevé que un incidente grave
no va a poder cumplir el SLA se debe activar el procedimiento de crisis.
La tabla de la figura 8.1.3 permite calcular la prioridad en función de estas dos
variables.
Prioridad de un incidente
PRIORIDAD/ IMPACTO
Tiempo de resolución
Alto Medio Bajo
Alta Inmediata / Alto / Medio /

u Oro en min <1 h <2 h
URGENCIA
Media Alto / Medio / Bajo /

o Plata <1 h <2 h <6 h
Planificar /
Baja Medio / Bajo /
Cuando haya
o Bronce <2 h <6 h
hueco
si > SLA
Incidente grave Crisis
Figura 8.1.3. Ejemplo de cálculo de la prioridad de un incidente

en función de su impacto y de su urgencia
Solución provisional (workaround) y error conocido (KE)
UNE-ISO/IEC 20000-2
Siempre que sea necesario, la gestión error deje de existir (por ejemplo, por-
del problema debería desarrollar y que el servicio ya no se utilice).
mantener soluciones provisionales para La gestión del problema debería tener
permitir a la gestión del incidente ayu- acceso a la información sobre las áreas
dar a los usuarios o al personal a res- de negocio afectadas por los problemas.
taurar el servicio.
Se debería almacenar y mantener en la
Un error conocido sólo se debería base de datos de conocimiento, la infor-
cerrar cuando se haya aplicado satis- mación sobre las soluciones provisiona-
factoriamente un cambio correctivo o el les, su aplicabilidad y su efectividad.
Se entiende por solución provisional (workaround) de un incidente a cualquier solu-

ción utilizada para restablecer el servicio rápidamente y que no haya resuelto la
causa raíz del mismo. Esta solución, al ser provisional, no resuelve el defecto que lo
originó, pero permite que los usuarios continúen su trabajo. Las soluciones provi-
sionales utilizadas deben registrarse, identificando el elemento de configuración
relacionado, pues ocultan defectos subyacentes que volverán a aparecer. En ocasio-
nes también se puede encontrar el término de solución rápida (quick fix).
Otro concepto utilizado en los procesos de resolución es el “error conocido” (KE,
Known Error). Se entiende como tal cuando la gestión del problema ha identificado
un defecto subyacente y la forma de resolverlo. Un error conocido es un fallo cuya
causa es conocida. Es decir, es la causa raíz ya identificada que provoca el incidente.
El error conocido lleva implícito las explicaciones, el conocimiento y las soluciones
para la resolución de los incidentes provocados por este defecto. Una de las misio-
nes de la gestión del problema es la eliminación de los errores conocidos.
8.2. Gestión del incidente 545
8.2. Gestión del incidente
Figura 8.2.1. Actividades principales del proceso de gestión del incidente
La permanencia en su puesto del director de sistemas de información (CIO, Chief

Information Officer) depende claramente de que su organización sepa resolver, tanto
las grandes crisis, como los incidentes y peticiones diarias que llegan a TI. Aunque
este no es el único factor, sí es quizás el primero a considerar, pues de él depende la
confianza del negocio en TI.
Los incidentes son una consecuencia del resto de las actividades de TI. En ellos
influye la calidad del desarrollo, el cumplimiento de las políticas de pruebas, la soli-
dez de la arquitectura, la robustez de las plataformas, la calidad de los técnicos, la
estabilidad de los productos, el desempeño de todos los otros procesos, etc.
La gestión del incidente se centra en apagar los “incendios” rápidamente, dejando
de lado la eliminación de los defectos subyacentes en los servicios, que se deberán
corregir en el proceso de la gestión del problema. Mientras que no se erradiquen
todos los defectos, la gestión del incidente seguirá resolviendo las incidencias una
tras otra de la forma más rápida posible, comunicando a la gestión del problema
los defectos que encuentre en su día a día.
Así, la gestión del incidente es el proceso que se ocupa del tratamiento de los sucesos
que provocan la degradación o pérdida del funcionamiento normal de un servicio,
con el objetivo fundamental de recuperar el servicio para el negocio lo más rápida-

mente posible.
En ISO/IEC 20000, al igual que ocurre en ITIL v2, la gestión del incidente tam-
bién incluye el tratamiento de peticiones de servicio o solicitudes de los usuarios
relacionadas con TI. En este caso, el objetivo es atenderlas de forma eficiente y den-
tro de los plazos acordados. Pero por desgracia, este importante proceso práctica-
mente no se desarrolla en ninguno de estos dos marcos de referencia.
Produce cierta confusión que la gestión del incidente se divida a su vez en la propia
gestión del incidente y en la gestión de peticiones. También se debe aclarar que en
este proceso cuando se habla de incidente o de ciclo de vida de incidente, se suele
referir al incidente propiamente dicho y no incluye a las peticiones.
Se ha tenido que esperar a ITIL v3 para que la gestión de las peticiones (request ful-
fillment) haya sido reconocida y tratada como un proceso específico. La atención a
las peticiones es una fuerte carga de trabajo en las áreas de producción o explota-
ción de TI, de ahí la importancia en desarrollar unos procedimientos y mecanismos
para alcanzar la máxima eficiencia en su resolución.
En la figura 8.2.2 se presenta un esquema introductorio al proceso de gestión del
incidente.
La misión del proceso de gestión del incidente es restaurar el funcionamiento nor-
mal del servicio para minimizar el impacto negativo sobre el negocio, garanti-
zando de este modo que se mantiene el más alto nivel de calidad y disponibilidad
del servicio. El “funcionamiento normal del servicio” se entiende aquí como el
funcionamiento del servicio dentro de lo previsto (según lo recogido en el acuerdo
de nivel de servicio o SLA), de tal forma que el negocio no vea interferida su acti-
vidad.
En la prestación de los servicios no se debe aspirar a mediocridades. Se debe buscar
que los servicios no fallen, pues un incidente es una privación de algún servicio y,
por tanto, siempre va a producir un trastorno en la actividad de la empresa. Por
ello, los plazos de resolución de los incidentes, en los acuerdos de nivel de servicio
(SLA), han de ser tomados como límites que no se deben traspasar y nunca como
el desempeño esperado de la función de TI.
Los objetivos de la gestión del incidente son los siguientes:
• Minimizar el tiempo de resolución de los incidentes.
• Priorizar la atención de incidentes de acuerdo con los compromisos de servicio.
• Reducir el impacto de los incidentes gracias a una resolución oportuna,
incrementando de este modo la eficiencia del negocio.

del incidente • Prioriza la atención de incidencias
de acuerdo con los compromisos de
servicio.
Definición:
• Reduce el impacto de los incidentes
Proceso que se ocupa del tratamiento poniendo foco en la restauración
de los sucesos que provocan la cuanto antes del servicio.
degradación o pérdida del
• Almacena información de los
funcionamiento normal de un servicio,
incidentes producidos.
con el objetivo fundamental de
recuperar el servicio para el cliente • Gestiona el conocimiento en relación a
lo más rápidamente posible. la resolución de incidentes.
Además, gestiona las peticiones de • Mejora la eficiencia en el tratamiento
servicio para atenderlas de la forma de los incidentes y peticiones de los
más eficiente y rápida posible. usuarios.
• Colaborar en la identificación
Objetivo: proactiva de mejoras en los servicios
y en los procedimientos.
Restaurar el servicio acordado con el
negocio tan pronto como sea posible y
responder eficientemente a las
peticiones de servicio.
Figura 8.2.2. Introducción al proceso de gestión del incidente
• Colaborar en la identificación proactiva de mejoras y modificaciones para los

servicios.
• Atender a tiempo las peticiones de servicio de los usuarios.
• Optimizar los procedimientos de atención y resolución, incrementando de
este modo la eficiencia en el trabajo diario.
• Mejorar la satisfacción de clientes y usuarios.
La gestión del incidente es el proceso que más volumen de trabajo genera en TI.
Además involucra a un número de actores bastante amplio, desde los teleoperado-
res, pasando por todas las áreas técnicas, hasta llegar a los desarrolladores de las
aplicaciones.
Hay que tener en cuenta que en una organización de TI se atienden entre 2 y 3
contactos por mes de cada usuario, relativos a incidentes y peticiones de servicio
(una empresa de 5.000 personas generará unas 15.000 llamadas al mes que TI
deberá atender). Además, hay que considerar que la tendencia es a que este volu-
men de contactos se vaya incrementando, debido al aumento de la diversidad de
dispositivos móviles y a la progresiva penetración de las TI en la actividad de la
empresa. Por ello, es importante disponer de una organización perfectamente pre-
parada y entrenada para su atención y resolución.
Una buena gestión de los incidentes y las peticiones en la organización, reducirá
enormemente las tensiones internas y permitirá a la organización salir de la crisis
continua como único medio de gestión y de trabajo. Además, liberará a la direc-
ción de TI de llamadas y quejas inoportunas de los otros directores, permitiendo
que en la organización de TI cada uno realice su propio trabajo.
Por tanto, es un proceso que tiene dos flujos de trabajo (workflow) diferenciados y
amplios, que se deben afinar y optimizar. El primero de ellos es el ciclo de vida del
incidente y el otro el ciclo de vida de la petición de servicio. Ambos comienzan en
el mismo punto, el centro de servicio al usuario (SD, Service Desk) que atiende los
contactos del usuario, bien sea a través de llamadas telefónicas o, más reciente-
mente, a través de una aplicación web. A partir de este momento, el flujo de ambos
procesos se separan para recorrer diversas partes de la organización de TI: el inci-
dente se trata por los niveles técnicos especializados y las peticiones por la adminis-
tración de los servicios.
Ya que estos dos flujos recorren gran parte de la organización, hay que transmitir a
todos los implicados los objetivos que se deben cumplir, para que TI actúe como
un auténtico equipo sincronizado. Los tres pilares en los que se sustenta este pro-
ceso se resumen en la figura 8.2.3.
Figura 8.2.3. Bases de la gestión del incidente

Vocación de servicio. La vocación de servicio al usuario es el eje central de la organi-

zación de TI y uno de los aspectos que se deben cuidar y desarrollar en este proceso.
La amabilidad, la capacidad de explicación y la comunicación son facetas importantes
que deben desarrollar las personas que están en contacto con los usuarios.
Tiempo de resolución. Este proceso es una fábrica masiva de resolución, tanto
de los incidentes como de las peticiones. El concepto de pertenencia a la “cadena de
resolución” debe estar mentalmente asumido por todos los participantes. Los invo-
lucrados en la cadena deben ser conscientes de la importancia del cumplimiento de
los plazos. Las herramientas de gestión de incidentes y peticiones deben facilitar el
control de los tiempos de resolución. Además, deberán activar las alarmas y priori-
zar los incidentes o peticiones (tickets) cuando el plazo de resolución está próximo
a su expiración.
Conocimiento técnico. No hay que olvidarse de la importancia fundamental del
conocimiento técnico del personal. Los proyectos de implantación de procesos en
las organizaciones de TI hacen que la dirección se centre en las formas de trabajar y
pudiera ocurrir que se dejara en un segundo plano el conocimiento técnico. Esto
no es lo que debería suceder, ya que un buen conocimiento técnico permitirá resol-
ver un incidente en minutos, mientras que un técnico “iletrado” generará percances
en la más mínima actuación y desbaratará cualquier planificación o compromiso
adquirido.
A la hora de estructurar los equipos de personas, el proceso de gestión del incidente
se articula normalmente en torno a tres líneas o niveles de atención y soporte téc-
nico: la primera línea o centro de servicio al usuario (service desk), la segunda línea
o soporte técnico especializado, y la tercera línea o soporte técnico de fabricantes o
suministradores. En la figura 8.2.4 se presentan los componentes más destacados
de este proceso.
Los componentes que intervienen en el proceso de gestión del incidente son:
Incidente (o incidencia). Cualquier suceso que no forme parte del funciona-
miento estándar de un servicio y que motive, o pueda motivar, una interrupción o
reducción de la calidad del servicio y de la productividad del usuario.
Petición (o solicitud) del usuario. Contacto del usuario para requerir a TI la pro-
visión de una funcionalidad individual ya prevista en el catálogo de servicios, por
ejemplo, un nuevo ordenador personal, alta como usuario en una aplicación, una
consulta sobre el uso de un servicio, etc.
La diferenciación entre usuario y cliente en este proceso se aprecia en todo su deta-
lle, pues, conviene no confundir las peticiones de los usuarios, que siempre son de
carácter individual, con las demandas de carácter colectivo de los clientes (o áreas
cliente) para requerir un nuevo servicio o la evolución de uno existente.

Eventos de
monitorización
Ticket Escalado
Incidentes
Personal
técnico
Incidentes
Primera línea Segunda línea Tercera línea

Peticiones de soporte, de soporte de soporte
service desk o centro (áreas técnicas (fabricantes y
de servicio al usuario internas) suministradores)
Usuarios
Problemas
identificados Conocimiento
técnico
Peticiones de
Incidentes cambio (RFC) Errores
conocidos CMDB
Base de datos Solución temporal Base de datos Base de datos

de incidentes (work-around) de problemas de configuración
Figura 8.2.4. Las líneas de atención y soporte son el eje de

la gestión del incidente
Problema. La causa raíz desconocida de uno o más incidentes existentes o poten-

ciales. Los problemas pueden ser identificados a través de varios incidentes que
muestren síntomas comunes. También pueden identificarse a partir de un incidente
de relevancia, indicativo de un error con causa desconocida. La gestión del inci-
dente o el service desk comunican a la gestión del problema los problemas que iden-
tifiquen como consecuencia de estar continuamente reparando incidencias.
Error conocido (KE, Known Error). Es un defecto del que se ha identificado la
causa raíz que lo originó (se tenga o no una solución, sea temporal o permanente).
Los errores conocidos son una pieza clave en la gestión del conocimiento para la
resolución de incidentes.
Los problemas y errores son tratados exclusivamente por el proceso de gestión del
problema.
Solución provisional (workaround). Es una solución temporal a un incidente con

el fin de restaurar rápidamente un servicio. Las soluciones temporales no eliminan
o resuelven la causa raíz que causó el incidente, pero permiten restaurar el servicio
(véase el apartado 8.1).
Ticket. Se suele denominar ticket a la ficha de registro de un incidente, bien sea un
incidente como tal o una petición del usuario. A cada incidente se le asigna un
número. En la literatura de origen anglosajón, al flujo que conduce a un incidente
desde su registro inicial, como ticket en una herramienta, hasta su cierre se le deno-
mina trouble ticketing (gestión de tickets de dificultades), en realidad este término
representa al propio ciclo de vida de un incidente.
Primera línea de atención o centro de servicio al usuario (SD, Service Desk).
Equipo de personas que recibe los contactos de los usuarios (llamadas, mensajes,
tickets, etc.), los registra y clasifica, e intenta resolverlos o remitirlos a los grupos de
soporte adecuados. Es importante destacar que el service desk es el único punto
de contacto del usuario con la organización de TI (SPOC, Single Point of Contact).
Todo incidente o petición se comunica vía service desk. Es también el punto de
comunicación de vuelta desde TI hacia el usuario para informarle del avance de sus
peticiones o del cierre de los incidentes. El SD también recibe incidentes generados
por los sistemas de monitorización. El centro de servicio al usuario es conocido
como nivel 1 de atención o primera línea de soporte.
Segunda y tercera líneas de soporte. Realizan las funciones técnicas de soporte
especializado. Se encargan de resolver los incidentes que provienen del service desk.
Reciben el ticket del incidente, investigan y resuelven el incidente y, una vez
resuelto, lo comunicarán al SD. En las líneas segunda y tercera participan gran
parte de la organización de TI, pues los especialistas suelen estar agrupados en gru-
pos tecnológicos.
Evento de monitorización. Es una notificación de un posible incidente generada
automáticamente por las herramientas de monitorización. Este evento llega al
service desk para su evaluación.
Call center, centro de contactos o centro de llamadas. En las grandes organiza-
ciones es frecuente encontrar el centro de servicio al usuario dividido entre dos
equipos de personas diferentes: el de recepción exclusiva de llamadas y el de resolu-
ción de primera línea. El call center o centro de contactos se encarga únicamente de
registrar las llamadas y abrir una ficha del contacto con el usuario. La llamada y la
ficha pasan al soporte técnico de la primera línea para su resolución.
Escalado. Es la actividad de remitir un incidente a otro grupo de TI para que con-
tinúe su resolución. Por tanto, el escalado es el mecanismo que permite el traspaso
de información y requerimientos de actuación sobre un incidente a las líneas o
niveles predefinidos y especializados de resolución, contribuyendo a que los inci-

dentes se resuelvan a tiempo.
Hay dos tipos de escalado, escalado funcional (o enviar a otra línea de soporte) y
escalado jerárquico (comunicar situación).
Base de datos de incidentes. Repositorio que contiene la información de los inci-
dentes ocurridos. Además suele incluir también las peticiones y consultas. Contiene
los registros o fichas de los incidentes registrados, junto a la información sobre su
resolución. Esta base de datos va ligada a la herramienta de gestión del incidente o
de atención al usuario. Registra la actividad de resolución de los incidentes y suele
contener una breve explicación de la resolución, por lo que contribuye al conoci-
miento de la organización en relación a estos temas. Es una de las piezas que utiliza
el service desk para la conocer cómo se ha resuelto de incidentes similares. La ges-
tión del problema busca en ella para identificar defectos latentes que se deban resol-
ver. Contiene información detallada de los incidentes y su resolución con la
siguiente información:
• Incidentes resueltos y cerrados con las soluciones temporales.
• Toda la información relevante asociada con el incidente
• Información relativa a la comunicación con el usuario.
• Explicación de la resolución con la fecha y hora.
• Información de todos los grupos intervinientes detallando sus tiempos con-
sumidos.
• Etc.
Petición de cambio (RFC, Request For Change). Medio para proponer un cam-
bio en cualquier componente de la infraestructura de TI o en cualquier aspecto de
un servicio de TI. La gestión del incidente genera las peticiones de cambio que
necesite para la resolución rápida de los incidentes abiertos.

Como se ha comentado anteriormente, la gestión del incidente tiene dos grandes
flujos de actividad: el ciclo de vida del incidente y el ciclo de vida de la petición de
servicio. Estos dos flujos tienen un inicio común en la primera línea de soporte que
realiza el service desk. A partir de aquí, y tras su clasificación, se separan en dos.
Otras actividades de la gestión del incidente, son la generación de las peticiones
de cambio (RFC) que se necesiten para resolver los incidentes, la identificación de
posibles causas recurrentes de incidentes (generando tickets de problemas) y la

supervisión de la evolución de los incidentes y la mejora del proceso.
La figura 8.2.5 muestra las entradas, actividades y salidas del proceso.
Desencadenantes 3 Ciclo de vida del incidente: Salidas principales:

del proceso: • Autorregistro y Ü Comunicación al usuario
Ü Contactos de los autorresolución por parte con incidente resuelto.
usuarios. del usuario. ÜBase datos incidentes.
Ü Eventos de • Detección y registro del
monitorización. incidente. Salidas secundarias:
• Clasificación y soporte inicial. Ü Petición de cambios
Entradas de soporte: (RFC).
• Asignación y escalado.
Ü CMDB. Ü Información de gestión.
• Investigación y diagnóstico.
Ü BD de incidentes. Ü Información de la
• Reparación y recuperación.
Ü BD de problemas existencia de un
(errores conocidos). • Cierre del incidente. problema.
Ü SLA. 3 Generar peticiones de cambio Ü Encuestas de
Ü Catálogo de servicios. para resolución de incidentes. satisfacción de los
3 Comunicar problemas detectados. usuarios.
3 Gestión de incidentes graves.
3 Ciclo de vida la petición usuario.
3 Supervisión y mejora del
proceso.
Las principales entradas a este proceso son:

Contactos de los usuarios. Para comunicar incidentes, consultas, solicitudes,
reclamaciones o reaperturas de los incidentes, etc., relacionados con los sistemas de
información.
Eventos de monitorización. Se reciben los eventos o alertas desde las herramien-
tas de monitorización, que pueden estar relacionados con:
• Hardware: servidores, discos, routers, impresoras, etc.
• Comunicaciones y telefonía.
• Software: aplicaciones, otros sistemas, utilidades, etc.
CMDB. Base de datos de gestión de la configuración, utilizada frecuentemente

para conocer que elementos de configuración pueden estar afectados por un inci-
dente, los servicios afectados y sus relaciones. También se utiliza para conocer el
catálogo de servicios, los SLA, autorizaciones de usuarios, documentación, ubica-
ción, etc.
BD de incidentes. La base de datos de incidentes donde se registran y controlan
las fases por las que pasan los incidentes. Proporciona información para controlar
que no se abra más de un incidente por la misma causa y para identificar incidentes
anteriores y sus soluciones.
BD de problemas. La base de datos de problemas se utiliza para identificar si el
incidente en curso está provocado por un error conocido, y por tanto, saber la
forma de solucionarlo.
SLA. Los acuerdos de nivel de servicio facilitan la información necesaria para prio-
rizar el incidente y para conocer el plazo pactado para su resolución.
Las actividades del proceso se dividen entre las relativas a los incidentes, las de
tratamiento de las peticiones y las de mejora. Más adelante se describen con
detalle.
Las principales salidas de este proceso son:
• Comunicación al usuario. Información de salida hacia el usuario para man-
tenerle informado sobre el estado del incidente o bien al final para confirmar
su resolución.
• Base datos de incidentes. Se obtiene como salida una base de datos con los
incidentes registrados y el tratamiento realizado.
• Peticiones de cambio (RFC). Se remiten las peticiones de cambio, cuando
se requieran, para solventar los incidentes.
• Información de gestión. Se genera la información relevante para la gestión
y mejora del proceso (indicadores de gestión y métricas).
• Información de la existencia de un problema. Se remite a gestión del pro-
blema la información relativa a posibles problemas encontrados en el trans-
curso de la actividad de gestión del incidente.
• Encuesta de satisfacción del usuario. Realizada en el cierre de cada inci-
dente.
Ciclo de vida del incidente

Observando los volúmenes de actividad en TI, se aprecia que la gestión de los
incidentes, de las peticiones de usuario y de los cambios, son los tres grandes
ciclos de frenética actividad que giran y giran continuamente en una organi-
zación.
En la figura 8.2.6 se muestra el ciclo de vida de un incidente, en su transcurrir por
las líneas de soporte 1, 2 y 3. También se muestra su paralelismo con el ciclo de
vida de una petición de servicio.
Fuente: Libros ITIL Soporte de Servicio y Operación del Servicio publicados por OGC.
Figura 8.2.6. Ciclo de vida del incidente
En ISO/IEC 20000-1 están condensados los requisitos para la gestión del inci-
dente. En ella se especifica lo siguiente:
UNE-ISO/IEC 20000-1
Se deben registrar todos los incidentes.

Se deben adoptar procedimientos para gestionar el impacto de los incidentes.
Los procedimientos deben definir el registro, la priorización, el impacto en el nego-
cio, la clasificación, la actualización, el escalado, la resolución y el cierre formal de
todos los incidentes.
ISO/IEC 20000-2 indica lo siguiente:
UNE-ISO/IEC 20000-2
El proceso de gestión del incidente e) la verificación y el cierre de los

debería incluir lo siguiente: incidentes;
a) la recepción, el registro, la asig- f) el contacto de primera línea con
nación de prioridad y la clasifica- los clientes;
ción de las llamadas; g) el escalado.
b) la resolución de primera línea o la
Todos los incidentes se deberían regis-
derivación;
trar de modo que la información rele-
c) la consideración de cuestiones de vante se pueda recuperar y analizar.
seguridad;
d) el seguimiento y la gestión del
ciclo de vida de los incidentes;
Detección y registro del incidente

La primera actividad en el ciclo de vida del incidente es la detección. Idealmente, el
incidente debería ser detectado por las herramientas de monitorización. Pero, con
demasiada frecuencia, es el propio usuario el que lo detecta y lo sufre, y quién
informa al service desk, bien mediante una llamada de teléfono o bien mediante su
registro en una aplicación web (autorregistro).
Una vez detectado debe ser registrado en la herramienta de gestión de incidentes. Es
posible registrar directamente como incidente un evento o alarma captada por alguna
herramienta de monitorización. La dificultad estriba en la forma de tratar las alarmas
para discriminar entre las informativas, preventivas, críticas o fatales. La monitoriza-
ción deberá permitir detectar un incidente antes de que sus efectos afecten al servicio.
El objetivo es evitar la degradación del servicio y anticiparse a su caída.
Las tareas que habitualmente se realizan en la detección y registro son las siguientes:
• Comprobar que la comunicación del usuario o el ticket abierto automática-
mente por la monitorización corresponde de verdad a un incidente.
• Registrar los datos preliminares en la ficha o pantalla de registro de incidentes
(bien por el teleoperador del service desk o directamente por el usuario vía web).
• Si se trata de un incidente, verificar que no se ha registrado previamente, en
cuyo caso se asocia con el incidente existente. Si no existe, se graba como
incidente nuevo.
• Si se trata de una petición o solicitud de servicio o similar, se graba el regis-
tro con los datos requeridos para tramitarla.
En la figura 8.2.7 se muestra un ejemplo de la estructura de la ficha de un inci-

dente, que se irá cumplimentando según progrese en su ciclo de vida.
Ficha de un incidente
3 Datos de identificación del usuario que abre

la incidencia: nombre, teléfono, etc.
3 Fecha de apertura del incidente.
3 Datos descriptivos del incidente:
• Efecto percibido por el usuario
(tipificación de entrada).
• Servicio o aplicación. Grupo.
• Prioridad.
• Detalles.
• Causa del incidente.
• Efecto real.
• Objeto fallo.
3 Datos descriptivos de la resolución:
• Fecha de resolución.
• Causa final del incidente.
• Solución aplicada.
• Descripción de la resolución.
3 Datos descriptivos del cierre.
Fuente: Libros ITIL Soporte de Servicio y Operación del Servicio publicados por OGC, y Telefónica.
Figura 8.2.7. Ficha o ticket tipo de un incidente

Autorresolución por el usuario

Esta funcionalidad ofrece la posibilidad al usuario de poder intentar resolver su
incidente o petición. Si lo consigue, no es necesario proceder al registro de una
ficha del incidente.
La aplicación de autorresolución suele ser distinta a la del autorregistro. Combina
una base de conocimientos de problemas genéricos relativos al ordenador personal
(conocimientos que se pueden comprar en el mercado como producto), con el
conocimiento de la propia empresa sobre la configuración del PC o de los servi-
cios. Además, la autorresolución puede llamar a aplicaciones o rutinas propias de la
organización para ejecutar acciones sencillas asociadas a la resolución de un inci-
dente o a la provisión automática (por ejemplo, el borrado de la contraseña de
usuario en una aplicación).
En la autorresolución es importante facilitar al usuario la búsqueda en la base de
datos del conocimiento, que permita identificar fácilmente la solución a su inci-
dente.
Autorregistro y clasificación por el usuario

Resulta tremendamente útil implantar un formulario web que permita a los usua-
rios el registro de los incidentes y las peticiones. Así, se alivia al centro de atención
de llamadas de la labor de registrarlos, con lo que se reduce drásticamente el
número de teleoperadores. También, se reducen los tiempos de espera al teléfono
de los usuarios para ser atendidos. Los registros dados de alta por los usuarios,
deben ser tratados inmediatamente por la primera línea de soporte, para poder
establecer contacto con el usuario si lo necesitasen. Una vez que el usuario se iden-
tifica, los datos de su puesto de trabajo se deben cargar en la aplicación de forma
automática, para evitar que introduzca una y otra vez la misma información.
En el autorregistro es muy importante disponer de una herramienta de ayuda a la
clasificación por el usuario del tipo de incidente o de petición, para poder automa-
tizar mejor la primera atención del ticket creado.
Asociado al autorregistro, conviene poner también foco en la resolución inmedia-
tamente posterior al registro del ticket, así se puede localizar al usuario en su puesto
de trabajo y se evitan importantes pérdidas de tiempo en sucesivos intentos de esta-
blecer contacto.
La autorresolución y el autorregistro son esenciales para reducir la carga de
actuaciones triviales de los grupos de soporte y proporcionan satisfacción al usua-
rio al permitirle resolver por sí mismo necesidades de una forma más ágil. Una
buena combinación de ambas puede reducir en un 30% el número de contactos

con el service desk.
Clasificación y soporte inicial

Está formada por dos actividades: clasificar el incidente y proporcionar una solu-
ción al incidente.
Clasificación. Establece la categoría del incidente y su prioridad. La clasificación
resultará fundamental para la comparación automática del incidente frente a las
bases de datos de problemas y errores conocidos.
La categoría de un incidente tiene como objeto identificar su origen, sus síntomas
y la causa (si es detectada); lo que permitirá localizar más fácilmente una solución
existente (error conocido) y su asignación a los grupos de soporte adecuados. En la
figura 8.2.8 se muestra un posible sistema de categorías.
Clasificación de un incidente
Categoría Subcategoría
Hardware Instalación/Configuración.
Rotura.
Factor humano.
Funcionalidad.
Software Inconsistencia/Corrupción.
Rendimiento/Bloqueos.
Factor humano.
Causa ajena a TI Servicios internos.
Defecto de fabricación hardware.
Bug software.
Red WAN.
Desconocido
Figura 8.2.8. Ejemplo de categorías de un incidente

En ITIL siempre que es necesario clasificar incidentes, peticiones o cambios se uti-

liza el mismo esquema, se les asigna un orden de importancia, denominada priori-
dad y que se asigna en función del impacto y de la urgencia (esta actividad se ha
descrito en el apartado 8.1 siguiendo la estructura de las Normas ISO/IEC 20000).
Así, la prioridad se establece en función del:
• Impacto en el negocio. Es la medida de la severidad para el negocio de un
incidente. A menudo se identifica con el grado en que el incidente lleva al
incumplimiento de los niveles de servicio acordados. También el impacto
está relacionado con el número de usuarios o sistemas afectados. Los crite-
rios para definir el impacto deben estar definidos en los SLA.
• Urgencia. Se refiere a la rapidez requerida para resolver un incidente de un
determinado impacto. Generalmente viene determinada por el tiempo dis-
ponible para la resolución del incidente sin afectar al servicio.
Normalmente se hará una distinción entre la clasificación realizada inicialmente

en el registro del incidente por el service desk, sobre la base de los síntomas, y la
clasificación final, sobre la base de conocer ya la causa real. El incidente podrá
reclasificarse a lo largo de su ciclo de vida.
En el momento del cierre es necesario revisar la clasificación ya que esta informa-
ción es clave para:
• Asociar el incidente con el elemento de configuración (CI, Configuration
Item) afectado, utilizando para ello la CMDB.
• Facilitar la identificación de los incidentes.
• Disponer de estadísticas fiables.
Soporte inicial. Una vez clasificado el incidente, se trata de resolverlo siguiendo

los siguientes pasos en secuencia:
• Comparación del incidente con los incidentes registrados en la base de datos
de incidentes, para ver si existen otros incidentes relacionados con este y, ade-
más, tienen una solución identificada. Si se encuentra un caso de estos se
salta a la actividad de reparación y recuperación para aplicar la solución.
• Comparación con los errores conocidos (KE, Known Error) y comprobar
si existe una solución que sirva para resolver el incidente. Si se encuentra, se
pasa a la actividad de reparación y recuperación del incidente.
• Utilización del conocimiento propio para encontrar una solución al inci-
dente.
En este paso, si se identifican incidentes repetitivos o taras en los componentes del

servicio, se generará un registro de problema. De la misma forma, se notificaría si
no se hubiera podido diagnosticar un incidente.
El soporte inicial finaliza, se haya resuelto o no el incidente, ya sea por falta de
conocimientos, medios o por expiración del plazo de tiempo determinado para su
resolución en esta línea. Si se ha resuelto el incidente se pasa a la fase de reparación
y recuperación.
Asignación y escalado
Cuando la primera línea no puede resolver el incidente, de forma inmediata lo
asigna al grupo técnico que corresponda en la segunda línea de soporte (escalado
horizontal). Si además, el incidente cumple unos requisitos definidos, se informa
inmediatamente a los responsables superiores (escalado vertical).
El escalado tiene el objetivo de resolver el incidente lo antes posible, para no
incumplir los niveles de servicio acordados. Es una actividad que puede ser itera-
tiva y que puede pasar por diferentes grupos de soporte e incluso a suministradores
hasta que se restaure el servicio.
Hay dos tipos de escalado:
• Escalado funcional (que equivale a enviar a otra línea de soporte). Es la
remisión de un incidente a otro grupo de soporte técnico o funcional para
que se continúe trabajando en él cuando es necesario aumentar la especiali-
zación necesaria. También se le conoce como escalado horizontal. Se realiza
generalmente desde los grupos de soporte de la primera línea a la segunda, o
de la segunda a la tercera. Es importante una buena tipificación del incidente
para conseguir que éste llegue al grupo de soporte adecuado. Los motivos
para promover un escalado pueden ser:
– El grupo que investiga la resolución del incidente no cuenta con los
conocimientos o experiencia requeridos para resolver el incidente. En
este caso, la petición partirá probablemente del equipo encargado de la
resolución.
– El tiempo disponible para la resolución del incidente pone en riesgo el
cumplimiento de los niveles de servicio acordados (SLA). En este caso,
el escalado puede ser también jerárquico.
• Escalado jerárquico (que equivale a comunicar situación). Es la notifica-

ción o información sobre un incidente hacia instancias superiores de mayor
jerarquía en la organización, normalmente con fines de informar o para soli-

citar una toma de decisión. Los motivos para un escalado jerárquico son:
– Comunicación. El tiempo disponible para la resolución del incidente pone
en riesgo el cumplimiento de los niveles de servicio acordados (SLA). El
incidente es grave o de alto impacto y las instancias superiores deben estar
informadas. Es necesario informar al cliente de que no pueden cumplirse
los niveles de servicio acordados.
– Decisión. Los recursos necesarios son importantes y la dirección y el clien-
tes tienen que estar informados. Es necesario tomar decisiones respecto a
la ampliación o aplicación de recursos.
La herramienta de gestión del incidente proporciona los medios para la asigna-

ción del incidente entre los diversos grupos técnicos de soporte (trouble ticke-
ting). El service desk debe supervisar todo el proceso y controlar mediante alarmas
internas los incidentes que se han quedado atascados en un grupo o que no se
resuelven.
UNE-ISO/IEC 20000-2
Siempre que sea posible, se debería cliente. Cuando la causa del problema
proporcionar al cliente los medios nece- siga sin determinarse pero se haya esta-
sarios para continuar con sus activida- blecido una solución provisional, se
des empresariales, aunque sea con un deberían registrar los detalles para utili-
servicio degradado (por ejemplo inhabi- zarlos durante la diagnosis continua del
litando una función defectuosa). El problema y cuando se produzcan inci-
motivo es minimizar la repercusión dentes similares.
sobre las actividades empresariales del
El service desk debe identificar la necesidad de proporcionar al cliente los medios

alternativos para paliar la ausencia del servicio de TI. Esta situación debe estar deta-
llada en el SLA y previstos los medios paliativos, si se puede.
En el momento en que se implemente una solución provisional para la resolución
del incidente (conocida como workaround), se debe registrar. En la herramienta de
gestión del incidente se identifica que el incidente se ha resuelto con una solución
provisional. La herramienta de gestión del problema mantendrá un registro con
todas las soluciones provisionales que haya activas.
Investigación y diagnóstico del incidente

El área de soporte técnico que recibe el ticket con el incidente asignado, realiza la
investigación de los síntomas y un diagnostico del incidente, antes de proceder a su
resolución. Aunque el diagnóstico y la resolución están separados como actividades
independientes, en la mayoría de los casos se realiza en un único paso.
El equipo encargado de la resolución del incidente deberá investigar utilizando
todos los medios, conocimientos y experiencia para resolver el incidente dentro de
los límites de tiempo acordados en los procedimientos de escalado.
En esta actividad se realiza la:
• Evaluación de los detalles del incidente.
• Recopilación y análisis de toda la información relacionada.
• Ampliación de la información en el registro del incidente con los detalles
resultantes de la investigación.
Si el equipo encargado de la resolución no es capaz de resolver el incidente en

plazo, se produce una nueva asignación y escalado. Esta acción podrá iterarse hasta
que se resuelva el incidente.
Existe el riesgo de que el personal de soporte se dilate en el análisis y no sea capaz
de controlar el plazo límite de ejecución que se tiene en el SLA, para realizar su
escalado funcional o jerárquico.
Reparación y recuperación del servicio

Una vez diagnosticada la causa del incidente y encontrada una solución, definitiva
o temporal, se procede a la reparación del fallo. Esta actividad contempla, tres eta-
pas distintas: la reparación del fallo en el elemento de configuración, la recupera-
ción del elemento de configuración y la restauración del servicio (momento en que
se reanudan las operaciones normales del negocio).
En la reparación, puede ser necesario contar con la autorización de la gestión del
cambio para aplicar la solución. Según sea la urgencia, se realizará una petición de
cambio normal o se actuará por el procedimiento de emergencia, generándose
en cualquier caso la correspondiente solicitud de cambio (RFC). La reparación del
fallo no implica necesariamente que el servicio haya vuelto a la normalidad, pues
igual hay que esperar a que se pueda reiniciar el sistema para que el servicio vuelva
a la normalidad. Una vez se ha recuperado el servicio, se informa o se pasa el ticket
al service desk.
Desgraciadamente, en la vida diaria las situaciones no son tan sencillas. Por ejemplo,
un fallo puede hacer que se haya corrompido una base de datos o que unos procesos
batch se hayan quedado a mitad y haya que reanudarlos y terminarlos, posiblemente
borrando datos incompletos y repitiéndolos desde el principio. También puede suce-
der que sea necesario recurrir a las copias de seguridad y avisar a clientes de que se han
perdido las últimas altas o facturas.
Estas situaciones complican a veces extraordinariamente la solución de un incidente
y generan discusiones sobre si los SLA se están cumpliendo o no. Por ejemplo, el
servicio se puede recuperar, pero reparar una base de datos corrupta puede llevar
días o semanas ¿Se puede decir que el servicio se ha recuperado hasta que la base
de datos esté limpia? Si ha fallado una cadena batch (programada en JCL), se puede
corregir y liberar una nueva versión, pero ¿termina el incidente con esto, o no ter-
mina hasta que el trabajo se ha lanzado otra vez y ha finalizado correctamente? El
servicio no se puede restablecer al cien por cien hasta que el trabajo batch haya fina-
lizado, pero es posible que no se pueda lanzar hasta la noche siguiente, aunque el
error en la programación en el JCL se haya corregido en minutos.
El equipo que solucionó el incidente, deberá actualizar el registro del incidente
cumplimentando los detalles propios de la resolución e información complementa-
ria, como por ejemplo:
• La fecha y hora de la resolución del incidente.
• El equipo que proporcionó la solución.
• El detalle de la solución.
• El detalle de los procedimientos y elementos utilizados en la resolución.
• Los incidentes relacionados, si los hubiese.
Cierre del incidente

El service desk recibe de vuelta el ticket del incidente ya resuelto, apareciendo en la
lista de tareas pendientes de tratar. Se pasa a obtener la conformidad del usuario
antes de proceder al cierre. La conformidad del usuario normalmente se realiza de
forma automatizada por la herramienta de gestión, que envía un correo infor-
mando de la restauración del servicio. A partir de aquí hay dos prácticas habituales:
• Una es pedir al usuario que de expresamente su conformidad respondiendo al
correo o entrando en la herramienta de gestión. Si el usuario no responde en
dos días se cierra de forma automatizada (no contando este plazo en el SLA).
• Otra práctica es cerrar por defecto todos los incidentes e informar al usuario
que puede reabrirlo si no está conforme con el cierre.
En los casos graves es recomendable obtener la conformidad del usuario directa-

mente a través los técnicos que están resolviendo el incidente y están ya en contacto
con él, o bien, o mediante una llamada telefónica del service desk.
UNE-ISO/IEC 20000-2
Un incidente sólo debería cerrarse defi- confirmar que el incidente se ha resuelto

nitivamente cuando el usuario que haya y el servicio ha sido restaurado.
notificado dicho incidente haya podido
En el momento de la comunicación del cierre, se suele adjuntar un enlace a una

página web en la que se le realiza una breve encuesta sobre la atención recibida.
Responder a la encuesta suele ser opcional para los usuarios. De esta forma se
obtiene información inmediata sobre la satisfacción del usuario.
Ahora bien, una vez que se decide realizar las encuestas a los usuarios, se deben
analizar y gestionar, tanto los resultados, como los comentarios recibidos y las que-
jas. Por desgracia, es común utilizarlas únicamente para obtener una métrica men-
sual o anual de satisfacción del usuario. Es el service desk el encargado de analizar
estas encuestas de forma regular (diaria o semanalmente) y de tomar las medidas
inmediatas adecuadas o realizar las propuestas de mejora que se incorporarán al
plan de mejora general del servicio. Las encuestas con valoración muy negativa,
deberían implicar el contacto con el usuario para conocer detalles de su punto de
vista sobre servicio recibido y, por otra parte, restaurar la confianza del usuario en
el servicio.
La responsabilidad del cierre del incidente recae en el service desk, de forma manual
o automatizada.
En el cierre de incidentes importantes, se deberá verificar que el registro del inci-
dente contiene toda la información necesaria y anexada la documentación apro-
piada. En el resto de incidentes, la comprobación puede ser hecha por una valida-
ción informática de los campos en el momento del cierre o por auditorías
periódicas de la base de datos de incidentes.
Reabrir el incidente
En caso de disconformidad del usuario con la resolución del incidente no se podrá
cerrar el incidente y volverá a la actividad de asignación, registrando en la informa-
ción del incidente que se ha reabierto.
En el caso habitual del cierre por defecto del incidente es muy importante tener
posibilidad de su reapertura para disponer de información estadística sobre la cali-
dad en la resolución. Se debe evitar la práctica de generar un nuevo ticket de inci-
dente, en lugar de reabrir el anterior.
En la reapertura, se registra en la base de datos de incidentes la causa de la reaper-
tura y la no conformidad del usuario.
Estados de un incidente
El estado de un incidente es un indicador del progreso realizado en su resolución.
Marca las diversas etapas por las que puede pasar el ticket de un incidente hasta su
resolución. El estado permite conocer al instante en que fase del flujo de resolución
se encuentra. Además, al marcar la evolución en etapas, posibilita extraer ciertas
métricas con el fin de evaluar el desempeño del proceso. En la figura 8.2.9 se mues-
tra un ejemplo de los posibles estados de un incidente.
Estados de un incidente (ejemplo)
Notificado.
Detectado.
Diagnosticado.
Reparado el fallo.
Recuperado el CI.
Restaurado servicio.
Cerrado.
Fuente: Libro ITIL Soporte de Servicio publicado por OGC y Telefónica.
Figura 8.2.9. Estados típicos de un incidente
A continuación se describen cada uno de los distintos estados asociados a un incidente:

• Notificado. Es el estado inicial y se produce en el momento en que el usua-
rio informa al service desk de la pérdida o perturbación del servicio. También
es posible registrar un incidente de forma automática a partir de los eventos

lanzados por los sistemas de monitorización de las infraestructuras y de los
servicios.
• Detectado. Indica que el incidente ha sido registrado y clasificado en la
herramienta de gestión del incidente.
• Diagnosticado. Se conoce la causa del incidente y se ha encontrado una
solución (normalmente temporal) al incidente. Permite obtener información
estadística sobre el tiempo que se tarda en diagnosticar y encontrar una solu-
ción al incidente.
• Reparado el fallo. Se logra este estado tras haber solucionado o reparado el
fallo del elemento de configuración (por ejemplo, en una infección de virus
se ha reparado el servidor infectado inicialmente).
• Recuperado el CI (Configuration Item o elemento de configuración).
Se pasa a este estado cuando se logra la recuperación del componente
(por ejemplo, en el caso anterior, se ha recuperado uno de los PC conta-
minados).
• Restaurado el servicio. Este estado se logra cuando se reanudan las opera-
ciones normales del negocio (por ejemplo, se han recuperado todos los pues-
tos infectados y el servicio del puesto funciona con normalidad).
• Cerrado. El usuario ha confirmado que el fallo se ha solucionado y se ha res-
tablecido el funcionamiento de las operaciones normales de negocio.
Un cierto detalle en los estados del incidente permite identificar en que etapas hay
que actuar para mejorar el proceso.
Modelos o patrones de incidentes y de peticiones

ITIL v3 introduce el concepto de “modelos del incidente” y de “modelos de la peti-
ción”. Muchos incidentes no son nuevos, sino repeticiones o similares a otros ante-
riores, por ello, puede ser interesante definir modelos o patrones de actuación ante
un tipo de incidente determinado. De la misma forma, las peticiones son clara-
mente repetitivas, por lo que tener tipificada su resolución aporta gran eficiencia al
proceso.
El modelo contiene una forma predefinida de los diversos pasos o tareas a realizar
para su resolución. La herramienta de soporte puede contener almacenada la
secuencia de intervención para estos incidentes tipificados.
Centro de servicio al usuario (SD, Service Desk)

El service desk es el único punto de entrada de incidentes. Es por tanto el único
punto de contacto con los usuarios, para recepción de incidentes y todo tipo de
peticiones y solicitudes de servicio. También recibe incidentes generados por los
sistemas de monitorización. Frecuentemente es conocido como primer nivel de
atención o primera línea de soporte.
El primer concepto a mantener en la implantación de este proceso es que el service desk
es el único punto de entrada para todos los contactos de los usuarios con TI. Todo
incidente y cualquier comunicación con el usuario deben pasar por el service desk.
UNE-ISO/IEC 20000-2
Nota 1: El proceso de gestión del incidente puede afecten, o que pudieran potencial-
ser proporcionado por un servicio de mente, afectar al servicio;
atención al cliente, que actúe como punto
b) un proceso centrado en la restaura-
de contacto diario con los usuarios.
ción del servicio a los clientes y no en
Nota 2: La gestión de incidentes debería ser: la determinación de la causa de los
incidentes.
a) un proceso tanto proactivo como reac-
tivo, que responda a los incidentes que
El service desk es el propietario de las incidencias y, por tanto, es el responsable de su

seguimiento hasta su cierre. Debe de estar alerta ante cualquier desviación o posi-
ble incumplimiento de los SLA en cuanto a los plazos para su resolución.
Se encarga fundamentalmente de realizar las siguientes acciones.
• Detección y registro del incidente.
• Clasificación del incidente y soporte inicial.
• Resolución del incidente en la primera línea de soporte, si se puede.
• Asignación y escalado funcional del incidente, si no se puede resolver en la
primera línea.
• A partir de este punto, las líneas segunda y tercera de soporte trabajan con
el incidente hasta resolverlo. Mientras dura esta etapa de trabajo interno, el
service desk y una aplicación web deben mantener informado al usuario, espe-
cialmente en incidentes importantes.
• Cuando es necesario, realiza el escalado jerárquico del incidente, haciendo de
intermediario en la comunicación con la dirección. Con frecuencia, muchos
de los escalados jerárquicos se realizan de forma automatizada por la herra-

mienta de gestión del incidente, cuando se cumplen las condiciones fijadas.
• Cierre del incidente. Comprobación con el usuario de que el incidente está
correctamente resuelto. Realiza las encuestas de satisfacción del usuario.
• Como propietario de los incidentes debe realizar un seguimiento de los inci-
dentes y las peticiones abiertos, con independencia del nivel en el que se
encuentren y con el fin de revisar si progresan adecuadamente para tomar las
medidas necesarias en caso contrario.
• Si un incidente no progresa, se deberá actuar poniendo en marcha las accio-
nes de escalado previstas.
• Seguimiento de los incidentes y peticiones abiertos, con independencia del
nivel en el que se encuentren. Controlar los incidentes que pasan por varios
grupos de resolución, coordinando los escalados horizontales a través de estos
grupos, con el fin de resolver los conflictos de competencias entre los distin-
tos grupos. Este control también servirá para detectar mejoras en la relación
existente entre la tipificación de los incidentes y los grupos de resolución.
• Hacer un seguimiento especial de los incidentes de prioridad alta.
• Mantener informados a los usuarios afectados sobre el progreso de resolu-
ción del incidente.
• Gestión de las peticiones de los usuarios.
• Reabrir el incidente, si lo reclama el usuario.
La función del service desk dentro del proceso de gestión del incidente, lleva a cabo
una labor importantísima. Aparte de centralizar todas las gestiones de seguimiento
del ciclo de vida del incidente, gestiona todas las comunicaciones de TI con el usua-
rio, en ambos sentidos, tanto para atender las llamadas como para emitir comuni-
cados o contactar con el usuario.
Lo recomendable es apoyarse en la herramienta de gestión del incidente para la
comunicación, que posibilita el acceso de los usuarios para consultar el estado de
sus incidentes y peticiones. Otro medio muy habitual es el correo electrónico y oca-
sionalmente debería ser el teléfono.
UNE-ISO/IEC 20000-1
Se debe mantener informado al cliente del progreso del incidente sobre el que haya
informado o de su solicitud de servicio, y se le debe alertar por adelantado sobre si sus
niveles de servicio no se pueden satisfacer, acordando con él las acciones a tomar.
UNE-ISO/IEC 20000-2
Se puede informar sobre incidentes ticamente mediante un software de

mediante llamadas telefónicas, buzón supervisión automática.
de voz, visitas, cartas, faxes o mensa-
jes de correo electrónico, o bien pue- El progreso (o su ausencia) de la resolu-
den ser registrados los avisos directa- ción del incidente se debería comunicar
mente por los clientes que tengan a las partes real o potencialmente afec-
acceso al sistema de registro de inci- tadas. Todas las acciones se deberían
dentes, o se pueden registrar automá- registrar en el registro del incidente.
Se debe poner foco en que el service desk, como primera línea de soporte, resuelva
el mayor número de incidentes y peticiones posibles; de esta forma, se reducirá
la carga de trabajo de todo el resto de la organización de TI. Para ello, es necesa-
rio contar con perfiles más cualificados que los tradicionales teleoperadores y
poner énfasis en una buena documentación que contenga los procedimientos de
resolución.
Dado el alto volumen de incidentes que se gestionan, es recomendable disponer
de una herramienta que, mediante reglas, realice el escalado funcional o jerárquico de
los incidentes de forma automática y envíe notificaciones a los gestores del proceso,
que les permitan reaccionar antes de rebasar los plazos del nivel de servicio pactado.
Esto libera a los supervisores del service desk de la ardua tarea de descubrir, en las
colas de trabajo, qué incidentes están a punto de superar su SLA. El tiempo de
resolución y las métricas clave del proceso se mejoran sustancialmente en cuanto
se implanta esta automatización.
Los resultados de las encuestas de satisfacción también mejoran cuando, mediante
otra automatización, se informa a cada usuario del estado de su incidente y de sus
ajustes, ofreciendo transparencia en la gestión.
Se recomienda que el service desk realice también el tratamiento de las quejas o recla-
maciones de los usuarios, como instrumento esencial para la mejora del servicio y
la atención prestada. La recepción de quejas aporta información importante de
mejora y sirve para restaurar la confianza del usuario en el servicio. Las quejas de los
usuarios se deben registrar y valorar. También debe asegurarse de que se tomen
las acciones correctoras adecuadas. Toda queja debe tener una gestión asociada:
registro, seguimiento, informe al usuario y cierre.
En las Normas ISO/IEC 20000 en el único lugar en el que explícitamente se tra-
tan las reclamaciones y quejas es en el proceso de gestión de las relaciones con el
negocio (véase el capítulo 7). En ese proceso no se hace distinción explícita entre
reclamaciones de cliente o reclamaciones de usuario, por lo que podría entenderse

que sólo trata las de clientes. Pero la ausencia de referencias a la gestión de recla-
maciones de usuarios de forma explícita en algún otro lugar de la norma, lleva
a asumir que las relaciones con el negocio las trata todas, aunque sigue siendo el
service desk el único contacto para su registro.
El éxito del uso del service desk está siendo tal, que en muchas empresas empieza a
atender también otras peticiones de servicio externas a TI, relacionadas con los ser-
vicios generales de la empresa (facilities), como por ejemplo, reservas de sala, peti-
ción de material de oficina, etc. En este caso se amplia el concepto de punto único
de contacto para todo tipo de servicios (y no sólo para TI), pero es importante que
el service desk tenga siempre presente su misión prioritaria de resolución de inciden-
cias sobre otras peticiones que no suponen una pérdida de servicio.
Soporte de incidentes en segunda y tercera línea

Soporte de incidentes en la segunda línea (o soporte especializado interno) y en la
tercera línea (o soporte especializado del fabricante o suministrador) se encargan
de resolver los incidentes que el service desk no puede solucionar. Reciben la infor-
mación del incidente, lo investigan y resuelven, y se encargan de comunicárselo de
vuelta al service desk. Realizan el escalado funcional del incidente y solicitan el esca-
lado jerárquico al service desk, en caso de necesidad.
Las acciones principales de este subproceso son las siguientes:
• Investigación y diagnóstico del incidente.
• Asignación de un incidente a otras líneas de resolución (escalado), que se
realiza en función de:
– Los conocimientos requeridos para resolver el incidente
– El tiempo disponible para la resolución del incidente en función de los
acuerdos de nivel de servicio (SLA).
• Reparación del incidente y recuperación del servicio.
En el soporte de segunda línea intervienen todo un elenco de grupos especialistas

(servidores, almacenamiento, comunicaciones, sistema operativo, productos mid-
dleware, productos frontend, aplicaciones, etc.) que comparten su actividad entre la
resolución de los incidentes y la gestión técnica de su ámbito. El soporte de
segunda línea debe ser capaz de resolver por sí mismo la mayoría de los asuntos
técnicos, en el caso de que no pueda, lo escala a la tercera línea.
El soporte de tercera línea se sustenta en una serie de contratos de soporte (deno-

minados underpinning contracts o UC) que cubren la reparación de los defectos o
atención muy especializada. Estos contratos se deben suscribir con los fabricantes
(normalmente son contratos de mantenimiento y soporte del hardware y de los
productos software), con las empresas que realizan el desarrollo de aplicaciones
(para el mantenimiento correctivo) y con los suministradores de servicios (de tele-
comunicaciones, de operación, etc.). En estos contratos se debe velar porque los
niveles de servicio pactados sean iguales o más exigentes que los acuerdos de nivel
de servicio (SLA) firmados con los clientes (véase el apartado 7.2).
Generar la petición de cambio (RFC)

La gestión del incidente es una de las “fuentes” generadoras de peticiones de cam-
bio (RFC). Con frecuencia la resolución de un incidente requiere la realización de
una actuación o de un cambio en algún componente. En este caso, deberá generar
una petición de cambio (normal o de emergencia), siguiendo los procedimientos
dictados por el proceso de gestión del cambio.
Después de tramitar la solicitud de cambio, se hará un seguimiento del mismo para
su rápida ejecución. Una vez realizada la implementación, se debe revisar el cambio
realizado con el fin de verificar que se han obtenido los resultados esperados. Esta
revisión, conocida como evaluación postimplementación (PIR), la realiza la ges-
tión del gestión del cambio y comunica los resultados a la gestión del incidente.
Comunicar los problemas y mejoras detectados

La gestión del incidente, que trata todos los días con los incidentes y peticiones, es
la mejor fuente de información para detectar los defectos permanentes en los com-
ponentes de los servicios. Subsanar estos defectos disminuirá el volumen de inciden-
tes y, con ello, la presión sobre TI. Los defectos encontrados en los servicios se debe-
rán comunicar a la gestión del problema siguiendo los procedimientos definidos.
Como también trata las peticiones de los usuarios, podrá identificar los aspectos de
mejora, tanto en los temas funcionales de los servicios para la reducción del
número de consultas, como para proponer soluciones de automatización en la pro-
visión de servicios.
Las mejoras identificadas en los servicios se comunican a la gestión de nivel de
servicio para que las incorpore en el programa de mejora del servicio (SIP). Por
otra parte, las mejoras identificadas en los procesos serán remitidas al propietario
del mismo y las de los grupos de soporte a sus responsables jerárquicos.
Acceso al conocimiento técnico

A menudo, la primera reacción ante un nuevo incidente no es la de consultar cómo
se resolvió un incidente similar. Lo habitual es centrarse inmediatamente en los sín-
tomas y precipitadamente emitir un diagnostico, que inexorablemente marcará el
rumbo de la resolución, hasta que alguien se dé cuenta de que el diagnóstico inicial
era erróneo.
Por otra parte, tampoco es fácil encontrar la información de soporte relevante entre
todos los comentarios que se insertan en los registros durante el ciclo de vida de un
incidente. Por ello, las Normas ISO/IEC 20000 ponen énfasis en el acceso al cono-
cimiento generado.
UNE-ISO/IEC 20000-1
Todo el personal implicado en la gestión del incidente debe tener acceso a informa-
ción relevante como, por ejemplo errores conocidos, resoluciones de problemas y la
base de datos de gestión de la configuración.
UNE-ISO/IEC 20000-2
El personal de gestión del incidente nados y errores conocidos, soluciones

debería tener acceso a una base de provisionales y listas de comprobación
conocimientos actualizada que contenga que ayuden a restaurar el servicio para la
información sobre técnicos especialistas, empresa.
incidentes anteriores, problemas relacio-
Es importante poner foco en el registro y la difusión del conocimiento técnico

sobre los servicios y sus componentes. Pero esta meta no es fácil en un proceso que
gestiona multitud de incidentes y peticiones diarias, en el que se están exigiendo
unos ratios de resolución muy altos. En esta frenética actividad diaria, es difícil
inculcar a los técnicos la disciplina de documentar el conocimiento sobre los casos
que les son asignados, no obstante es esencial realizarlo para reutilizar experiencias
y ser más eficientes cada vez. Lo más sensato es que los detalles de la resolución de
incidentes se comenten brevemente en la ficha del incidente y sólo haga un informe
para incidentes de especial relevancia o cuyos condicionantes “políticos” lo exijan.
En ITIL v3 se define un proceso dedicado exclusivamente a la gestión del conoci-
miento en TI, debido a que el conocimiento sobre los servicios lo genera toda la
organización: problemas con la base de datos de errores conocidos, incidentes con
las explicaciones en el ticket del incidente de las resoluciones realizadas, desarrollo

de aplicaciones con los manuales de arquitectura, operación y para el service desk,
las áreas técnicas con la documentación generada en el diseño de las infraestructu-
ras y las plataformas, etc.
Es importante la elección de la herramienta que soporta el conocimiento, pues
pocas herramientas permiten registrar adecuadamente la información (incluyendo
anexos), ni tampoco consultarla fácilmente. Normalmente, se utiliza la propia
herramienta de gestión del incidente y del problema para almacenar el conoci-
miento, pero también existen algunos productos independientes que realizan esta
función. Se requieren funcionalidades de clasificación y búsqueda típicas de gesto-
res documentales, que permitan diversas vistas del mismo conocimiento (según
perfiles), funcionalidades de búsqueda avanzadas y la gestión del conocimiento
obsoleto o no visitado, integración con otras herramientas, etc.
El conocimiento técnico registrado permite a la organización retener información
esencial sobre su instalación e independizarse algo de las personas que la soportan.
Teniendo en cuenta todos estos antecedentes, se recomienda tener presenta las
siguientes consideraciones:
• Facilitar al personal técnico el acceso a las bases de datos de errores conoci-
dos, CMDB, resolución de problemas, etc. como describe la norma, y evi-
dencie la disponibilidad ágil de esos recursos, mediante enlaces directos en la
interfaz de operación o en las herramientas de gestión.
• Los errores conocidos o incidentes, deberían comprender también los que
hayan sido detectados durante las pruebas en los entornos de desarrollo o
preproducción y que no hayan sido subsanados. Las buenas prácticas esta-
blecen que sólo cuando los defectos han sido subsanados por completo se
puede proceder a su puesta en producción, pero en numerosos casos, por
condicionantes de negocio, se autoriza su puesta en producción pese a la
existencia de defectos conocidos.
• Facilitar al personal técnico la consulta, mediante motores de búsqueda ági-
les, de los comentarios de los incidentes y mediante navegación por menús
en cascada clasificados por área técnica.
• Clasificar y permitir también búsquedas de los registros de incidentes por
tipologías o síntomas, por tecnologías, o por elementos de configuración
(CI), por servicios, grupos, técnicos, etc.
• Actualizar en el cierre la clasificación del incidente, pues seguramente haya
variado sobre la realizada inicialmente. Esto permite acceder sin errores en el
caso de incidentes similares.
• Foco también en la autorresolución. Crear conocimiento destinado a los

usuarios finales, para que puedan resolver por sí mismos algunos incidentes
o peticiones (por ejemplo, configuración del acceso remoto).
• Mantener una única base de conocimiento centralizada, clasificando los con-
tenidos por tipos de perfiles a los que van dedicados: personal técnico de la
línea 2, personal del service desk o primera línea y para usuarios.
• Comunicar al personal técnico las actualizaciones de la base de conocimien-
tos. Supervisar y verificar que todo el personal la conoce, sabe cómo acceder
y la utiliza.
• Importar y comprar el conocimiento. Los fabricantes disponen de bases de
conocimiento accesibles vía web, además, hay soluciones con información
de resolución técnica ya precargada, sobre todo en lo relativo al puesto de
trabajo.
• Procedimentar la forma en que el personal técnico documenta los incidentes
asignados, no permitiendo incluir comentarios accidentales asociados al ciclo
de vida (por ejemplo, “no se localiza al usuario”, “escalado a supervisor”,
“incidencia cerrada OK”, que no aportan nada a la base de conocimiento) y
garantizando la inclusión de comentarios esenciales de conocimiento sobre
el diagnostico o resolución (como: “el error muestra un mensaje con el
código VM2005”, “se aplica el parche RF12345 y funciona”, etc.).
• El conocimiento debe estar salvaguardado con criterios de alta disponibili-
dad y continuidad ante desastres, ya que cuando es imprescindible su utiliza-
ción es en casos de graves dificultades.
• Relacionar los procesos de gestión del incidente, del problema, el soporte
técnico y el desarrollo, para que el conocimiento creado en el día a día se
mantenga completamente actualizado y vivo entre todos. Una base de cono-
cimiento poco veraz, no confiable, poco ágil u obsoleta, dejará de ofrecer
confianza y caerá en el olvido.
Incidentes graves
Hay organizaciones de TI que se gestionan en base a crisis, que acaban marcando
el ritmo de trabajo del día a día. No hay nada peor que una crisis para desbaratar la
productividad. Pero las crisis se producirán, por lo que se debe predefinir el com-
portamiento de la organización ante estos incidentes graves. Estas normas tratan el
tema de forma expresa.
UNE-ISO/IEC 20000-1
Los incidentes graves se deben clasificar y gestionar de acuerdo con un proceso.
UNE-ISO/IEC 20000-2
Se debería definir claramente qué cons- Esto debería incluir una responsabilidad
tituye un incidente grave y quién está del escalado y una comunicación efica-
capacitado para llevar a cabo cambios ces entre todas las áreas implicadas en
en el funcionamiento habitual del pro- la resolución y hacia los clientes que se
ceso de incidentes/problemas. vean afectados por dicho incidente
grave.
Todos los incidentes graves deberían
tener en todo momento un gestor res- Nota: Este nivel de autoridad puede ser temporal
ponsable claramente definido. y aplicarse sólo mientras dure el incidente
grave.
La designación como responsable de un
incidente grave debería proporcionar los El proceso para un incidente grave
niveles de autoridad individual adecua- debería incluir una revisión que propor-
dos para la función de coordinar y con- cionará información al plan de mejora
trolar todos los aspectos de la resolución. del servicio.
En la clasificación de incidentes descrita, se establece como “prioridad inmediata”

los incidentes de impacto alto y de urgencia alta. Esta misma clasificación se debe
utilizar para definir qué es un incidente grave, que normalmente será el de “priori-
dad inmediata”.
En el caso de incidentes graves, al igual que en los cambios urgentes, se dispone de
un tratamiento especial: notificaciones a mandos, información a todo el equipo,
asociación de incidentes relacionados, con la misma causa común, etc.
Cuando un incidente grave excede o se dictamina que va a exceder el SLA, se debe
activar la situación de crisis, en la que deben estar procedimentadas las acciones que
se realizarán, quién deberá participar y la creación del comité de crisis. Es habitual
disponer también de una sala de crisis, adyacente a la sala de control, con todos los
medios necesarios para que el equipo predesignado para estas emergencias pueda
desempeñar su labor.
Entre los incidentes graves también se incluyen los desastres. Puede ocurrir que
un incidente grave, en un momento de su trayectoria, requiera la activación de
este plan cediendo el control al proceso de gestión de la continuidad (véase el
apartado 6.3).
Los incidentes graves, así como, todos los incidentes con un impacto alto, se deben
notificar en tablón de anuncios web de TI, y además, en la pantalla principal de la
herramienta de incidentes.
El objetivo que se pretende conseguir ante un incidente grave es su resolución en
un tiempo récord, minimizando el alto impacto que ocasiona. También es necesa-
rio mantener un flujo de comunicación constante entre las áreas técnicas resoluto-
rias y el comité de crisis, sin descuidar mantener puntualmente informadas a las
áreas cliente afectadas.
Normalmente, este tipo de incidentes son de obligada y cuidada documentación,
de la forma más extensa y eficaz posible. Requieren un informe especial, aparte del
seguimiento extraordinario y específico por parte de los gestores de nivel de servi-
cio, y de los gestores de los procesos implicados.
Ciclo de vida de la petición de servicio (request fulfillment)

Se entiende por petición de servicio a toda solicitud que realiza el usuario al área de
TI, contemplada en el catálogo de servicios, para requerir un servicio, realizar una
consulta o cualquier otro tipo de contacto (a excepción de los provenientes de fallos
o incidentes). Hay organizaciones que no hacen distinción del tipo de petición y
desarrollan un tratamiento común para todas ellas, así se considera también servicio
a la atención de consultas y de otros tipos de contactos de los usuarios. Otras orga-
nizaciones definen flujos distintos diferenciando las peticiones de servicio de las con-
sultas. Muchas peticiones de servicio suponen pequeños cambios, pero de muy bajo
riesgo y con un impacto muy bajo, por ello, se podrán tratar bajo el tipo de cambio
preautorizado (véase el proceso de gestión del cambio en el apartado 9.2).
La gestión de las peticiones de servicio es de gran importancia para el área de TI,
pues genera un gran volumen de actividad (posiblemente el 15% de toda la activi-
dad de TI) y presenta una casuística muy diversa. En ITIL v2 y también en
ISO/IEC 20000, se ha tratado como un subproceso dentro de la gestión del inci-
dente, aportando escasas buenas prácticas al mercado. En ITIL v3 ha subido de
categoría, ascendiendo al rango de proceso (proceso de gestión de peticiones en el
libro Operación del Servicio), lo que emplaza al sector a poner foco en la mejora de
la eficiencia y calidad en este área de actividad, hasta ahora ninguneada por los
estándares.
No se debe confundir el tratamiento de peticiones con la gestión de nuevos servi-
cios o nuevas necesidades del negocio. Las peticiones las solicita el usuario y están
tipificadas en el catálogo, mientras que las segundas sólo las demanda el represen-
tante de las áreas cliente. De aquí, la importancia en distinguir entre el rol del
usuario, como utilizador de los servicios, y el rol del cliente o área cliente, como
representante del negocio ante TI.
Como es lógico, los servicios que se pueden solicitar deben estar identificados el
catálogo de servicios de TI. Algunos ejemplos de peticiones de servicio son las
siguientes:
• Solicitud de alta en un servicio del tipo aplicación o solicitud de acceso a un
servicio existente.
• Petición de equipamiento. Solicitud de nuevos componentes (hardware o
software) relacionados con el puesto de trabajo.
• Petición de actuaciones en el puesto de trabajo. Configuración del acceso
remoto UMTS, instalación de actualizaciones de los controladores de dispo-
sitivo, etc.
• Petición de ejecución de servicios planificados, como por ejemplo, la ejecu-
ción de cadenas batch.
• Consultas funcionales o técnicas, preguntas o dudas del usuario sobre un
tema del ámbito de servicios de TI. Las preguntas pueden ser de índole téc-
nico o funcional. Para la resolución de consultas funcionales suele haber un
equipo funcional específico, bien vinculado al área de desarrollo, al área de
relaciones con las unidades de negocio o bien al área de negocio (en este caso
fuera de TI). En todos los casos, TI debe registrar y tramitar este tipo de
consultas.
• Reclamaciones o quejas. El usuario manifiesta su disconformidad con un
servicio prestado.
Las entradas de las peticiones, al igual que los incidentes, se realizan a través del
service desk, punto único de contacto para el usuario.
Establecido que TI sólo aceptará del usuario peticiones de servicio ya predefinidas
en el catálogo, la primera acción que se realizará es comprobar si la petición está
entre los servicios que ofrece TI y que el usuario tiene permiso para realizarla.
Como ya hemos comentado, las soluciones de autorregistro y autorresolución por
parte del usuario son esenciales para reducir la carga del soporte en TI. Automati-
zar al máximo la provisión, junto a una gestión eficiente y previsora de la capaci-
dad (número de licencias) y del stock (componentes) son elementos claves para
reducir los tiempos de entrega y aliviar la carga de trabajo rutinaria en TI. Permitir
al usuario conocer vía web la evolución de su petición, facilita la comunicación y
mejora la imagen de TI.
Las peticiones de servicio que llegan al service desk recorren el mismo camino que
los incidentes en las dos primeras etapas (las actividades de “detección y registro” y
“clasificación y soporte inicial”), pasando después a un itinerario propio. Destacar
que algunas peticiones requerirán un itinerario de aprobación jerárquica y del con-
trol presupuestario. En la figura 8.2.10 se muestra el ciclo de vida de una petición
de servicio, según la estructura propuesta en ITIL v3.
Figura 8.2.10. Ciclo de vida de la petición de servicio
También es necesaria la implantación de procedimientos livianos y ágiles relativos a

las aprobaciones internas de las peticiones, especialmente de las que tienen impacto
en los presupuestos de los departamentos.
En el cierre de peticiones, reaperturas y reclamaciones se deben seguir las mismas
políticas definidas para el incidente.

El éxito de la gestión del incidente se demuestra a través de:
• La reducción de los tiempos necesarios para la resolución de los incidentes.
• La disminución de los costes asociados a la resolución.
Todo proceso tiene una actividad (o subproceso) dedicada a la supervisión de las

actividades que se realizan, para asegurarse que se cumple lo planificado y que se
identifican las mejoras necesarias.
En el proceso de gestión del incidente es básico realizar un seguimiento continuo
de los incidentes y peticiones, para identificar deficiencias en los procedimientos o
en las formas de actuar de los diversos grupos de soporte. La vigilancia permanente
de este gran engranaje resolutor resulta esencial para mejorar la productividad de la
La actividad de supervisión y mejora envía las propuestas de mejora, para su trata-
miento y aprobación, al plan unificado de mejora de la gestión del servicio (véase
el capítulo 4) y deberán coordinarse con el área financiera de TI.

Las métricas del proceso se suelen dividir en tres ámbitos:
• Métricas relativas al service desk y la actividad de atención de llamadas o con-
tactos.
• Métricas relativas a al ciclo de vida del incidente.
• Métricas relativas a al ciclo de vida de la petición.
Al ser la gestión del incidente un proceso de gran volumen de actividad, toman

especial relevancia las métricas volumétricas y las de eficiencia en el desempeño.
Las métricas relativas a la función del service desk suelen contener información como
el número de llamadas atendidas, el número de contactos atendidos, el ratio de lla-
madas perdidas, el porcentaje de incidentes bien clasificados, los ratios de actividad
por persona, el porcentaje de contactos que son peticiones de servicio, los ratios de
autorregistro, el ratio de incidentes resueltos en la primera llamada, los incidentes
resueltos en la primera línea, etc.
En relación a la medición del ciclo de vida del incidente, los más representativos
son los siguientes:
• Tiempo medio de reparación o MTTR (Mean Time To Repair), es el tiempo

medio transcurrido desde que ocurre un incidente hasta que se restaura el ser-
vicio. Representa el tiempo que el servicio está caído (downtime). Esta métrica
suele estar asociada a otras métricas de disponibilidad como, por ejemplo, el
tiempo medio entre fallos o MTBF (Mean Time Between Failures), que es
el tiempo medio que tarda en fallar un servicio (uptime) y el tiempo medio entre
incidentes en servicios MTBSI (Mean Time Between System Interruptions), que
es el tiempo medio transcurrido entre dos fallos consecutivos en un servicio.
En la figura 8.2.11 se aprecia la diferencia entre ellas.
• Porcentaje de incidentes resueltos en plazo.
• Calidad en la asignación de los incidentes.
• Calidad de la documentación.
Figura 8.2.11. Métricas de resolución de incidentes junto a las de disponibilidad
Además, es habitual medir los ratios de incidentes autorresueltos por el usuario, el

porcentaje de incidentes reclamados, el coste medio de resolución de un incidente,
el porcentaje de incidentes resueltos, etc.
En la figura 8.2.12 se muestra el resumen de los indicadores más relevantes para
este proceso seleccionados por un grupo de trabajo de itSMF España.
Métricas principales del proceso (incidente)
de itSMF España
La medición del ciclo de vida de una petición se centra en ratios de agilidad, de efi-
ciencia y de satisfacción del usuario. Los más comunes son el volumen de peticiones
gestionadas, el volumen de peticiones según su estado, desglose de las peticiones por
tipo (de servicio, consulta, etc.), el tamaño de lista de peticiones de servicio pendien-
tes, el plazo medio de provisión por tipo de petición, las peticiones de servicio ter-
minadas en plazo, el número de quejas y reclamaciones, el coste medio de provisión,
la satisfacción del usuario con la gestión de peticiones de servicio, etc.
En la figura 8.2.13 se muestra el resumen de los indicadores más relevantes para
este proceso seleccionados en ITIL v3 (en el libro Operación del Servicio).

Como en el resto de los procesos, los roles intervinientes en este proceso se estruc-
turan en los roles propios del proceso y los roles ajenos al proceso (el gestor del
nivel de servicio).
Los roles propios del proceso (del ciclo de vida del incidente) son los siguientes:
• Gestor de incidentes. Es el responsable de que los incidentes y peticiones de
los usuarios se resuelvan con la máxima eficiencia y se cumplan los acuerdos
Métricas principales del proceso (petición)
Fuente: Libro ITIL Operación del Servicio publicado por OGC y e.p.
Figura 8.2.13. Métricas relevantes de la gestión de la petición en ITIL v3
de nivel de servicio. Está involucrado en el día a día del funcionamiento del

proceso y de los diversos grupos de soporte. Sus principales responsabilida-
des son las siguientes:
– Todas las actividades del proceso y asegurarse de que se realicen de forma
eficiente.
– Realizar el seguimiento de las métricas del proceso. Es el responsable último
de implantación del proceso y su configuración en las herramientas de soporte.
– Asegurarse de que todos los implicados están suficientemente involucra-
dos en el proceso.
– Coordinar el trabajo del personal de soporte de incidentes. Recibe el esca-
lado jerárquico de los incidentes.
– Autorizar el escalado jerárquico a la dirección, previa consulta al responsa-
ble de la gestión del servicio. O bien, define las reglas para la configura-
ción de los parámetros del escalado.
– Asegurarse de que se establecen unas buenas relaciones de trabajo con
todas las organizaciones implicadas, tanto internas como externas.
– Monitorizar la eficacia y eficiencia del proceso y hacer recomendaciones
sobre posibles mejoras.
– Analizar, proponer y verificar la revisión de la metodología de trabajo en

la resolución de incidentes y peticiones para su mejora.
– Elaborar la información de gestión del proceso.
– Velar por la calidad del soporte y la satisfacción del cliente/usuario.
• Gestor del service desk. Es el responsable del funcionamiento del personal que
forma el centro de servicio al usuario, incluidas las herramientas. Es otro de
los roles importantes del proceso. Sus principales responsabilidades son las
siguientes:
– Supervisar la operativa diaria del service desk.
– Vigilar el estado de los tickets o contactos abiertos.
– Preparar los planes de formación para el personal asignado.
– Analizar la carga de trabajo de su personal, su nivel de conocimientos y
los costes laborales asociados.
– Avisar y realizar el seguimiento de la pérdida y degradación de servicios.
– Supervisar el progreso de los contactos, y en su caso tomar decisiones ante
dificultades en su resolución.
– Informar de las desviaciones e incumplimiento de los acuerdos de nivel de
servicio (SLA).
– Realizar los informes necesarios, como por ejemplo, los informes puntua-
les de actividad a petición, los informes del progreso del contacto y los
informes detallados de la actuación del service desk.
• Teleoperador. Con frecuencia, en primera línea del service desk se pone un

conjunto de operadores telefónicos que únicamente realiza tareas de registro
de incidentes y de contacto con los usuarios. En este caso, esta línea de aten-
ción forma parte de la primera línea de soporte. La tendencia es reducir estas
posiciones de atención, reemplazándolas por herramientas de autorregistro.
• Especialista del service desk (primera línea). En el caso de no haber teleopera-
dores, atiende los contactos de los usuarios (llamadas de teléfono, autorre-
gistro web, etc.) y los registra generando un ticket del mismo. Resuelve con-
sultas sencillas, clasifica los incidentes, tramita las peticiones y mantiene
informado al usuario. Realiza un primer diagnóstico de la incidencia.
Resuelve todas las incidencias que puede, en esta primera línea de soporte,
para reducir el paso de trabajo a otros niveles más especializados y más caros.
Las que no puede resolver las escala a la siguiente línea de soporte (escalado
funcional). Resuelve o escala los incidentes abiertos por las herramientas de
monitorización.
• Especialista de soporte (líneas 2 y 3). Es el rol responsable de diagnosticar la
incidencia, resolverla, comprobarla, asignarla a otro grupo y documentarla.
Participa en la resolución “in situ” de incidentes que no pueden resolverse
desde una ubicación remota y en el tratamiento personalizado de las inciden-
cias de los usuarios de dirección. Está formado por grupos de especialistas
técnicos en la gestión de la tecnología, en la administración de las aplicacio-
nes y sus datos, o en el desarrollo de software. Incluye a los grupos internos y
al soporte de fabricantes y terceros.
• Administración y soporte al proceso del incidente. Apoya al gestor del inci-
dente en sus responsabilidades. Vela por la implicación de los equipos ante la
llegada de una incidencia crítica, asegurando que se cumplen los SLA. Coor-
dina los escalados entre grupos en caso de necesidad. Supervisa a los miem-
bros de las diferentes líneas de soporte. Participa en la resolución de conflic-
tos internos.
Los roles ajenos que son relevantes en este proceso son los siguientes:
• El responsable de gestión de la configuración, pues el acceso a la CMDB es
imprescindible para toda la actividad de la gestión del incidente.
• El responsable de problemas facilita soluciones y errores conocidos para la
resolución de nuevos incidentes.
• El responsable de la gestión del servicio vela por que todos los servicios cum-
plan los niveles pactados.
• El responsable de gestión de la entrega. Su proceso debe proporcionar for-
mación al service desk y a las otras líneas de soporte sobre los nuevos servicios
o evolución de los existentes.
• El responsable de la gestión del cambio debe proporcionar información de
todos los cambios en los componentes (CI).
• El propietario del modelo de gestión de TI (SGSTI) actúa como propietario
del proceso (process owner), define las actividades del proceso y se encarga de
la mejora continua del mismo. Todo ello, de una forma integrada con el
modelo de gestión de TI o SGSTI.
Roles del proceso (sólo ciclo de vida del incidente)
Responsable de la
SGSTI
Gestor del Administrador y

incidente soporte del proceso
Propietario del
modelo (SGSTI)
Gestor de la
configuración Especialista de Especialista de Especialista de
Gestor del service desk línea 2 línea 3
problema (proveedor TI) (fabricante)
Figura 8.2.14. Roles del proceso de gestión del incidente
Resumen
ISO/IEC 20000 e ITIL v2 tratan en un mismo proceso los dos ciclos de la gestión
del incidente y la gestión de la petición del usuario, porque ambos ciclos tiene una
parte común (el service desk) y con frecuencia se ve involucrado el mismo personal
técnico en su tratamiento. En cambio, en ITIL v3 se ha decidido separar estos
ciclos en dos procesos diferenciados, pues el primero debe restaurar cuanto antes el
servicio para que el negocio pueda seguir trabajando aportando productividad,
mientras que la gestión de peticiones atiende nuevas necesidades predefinidas al
usuario y otorga agilidad al negocio.
La gestión del incidente es un proceso esencial para apagar los “fuegos” que se
produzcan en TI y minimizar el impacto en el negocio de los fallos y caídas de los
servicios.
Es muy importante no olvidar la necesidad de buenos especialistas técnicos, sin los

cuales todo intento de mejora será inútil.
Hay que entrenar a los equipos de soporte en ser eficientes en su trabajo, principal-
mente a los especialistas de línea 2, pues deben compaginar su dedicación a resol-
ver incidentes rápidamente con otras funciones técnicas a medio plazo.
La información es esencial, tanto la proporcionada por la CMDB, como la obtenida
desde la base de dato del conocimiento (sobre incidentes, sobre problemas, etc.).
Disponer de una herramienta de soporte al proceso es algo irrenunciable.
Hay que poner foco en el autorregistro, la autorresolución y en la resolución de
incidentes en la primera línea.
Los incidentes y peticiones generan un gran volumen de actividad y tienen un flujo
que recorre gran parte de la organización, por lo que todo esfuerzo en su reduc-
ción y optimización aportará grandes beneficios.
Hay que prever y elaborar el procedimiento de actuación del soporte ante los inci-
dentes graves.
La gestión de conocimiento técnico, es una labor de toda la organización, no úni-
camente de este proceso. Se debe disponer de una herramienta de gestión del cono-
cimiento y gestión documental que facilite su almacenamiento y consulta.
Beneficios
Algunos de los beneficios de alcanzar una correcta gestión el incidente son los
siguientes:
• Resolución más rápida de los incidentes y reducción del impacto en el nego-
cio de los fallos. Se produce una mejora de la disponibilidad.
• El proceso pone foco en la restauración del servicio, como eje fundamental.
• Mejor alineación de TI con las necesidades en el día a día del negocio.
• Mejor atención a los usuarios.
• Tratamiento eficiente del alto volumen de actividad requerido. Implementa-
ción de herramientas de autoatención por parte de los usuarios.
• Mayor número de incidentes resueltos en primera línea, con lo que se alivia
la carga de trabajo de las líneas de soporte más especializadas.
• Estar preparado ante las crisis.
• Retención del conocimiento.

• Identificación de fallos recurrentes para que se solventen por la gestión del
problema. Mejora de la infraestructura.
• Oportunidad de mejora de los servicios, tanto en su resistencia al fallo, como
en su usabilidad.
• El service desk puede identificar nuevas necesidades de servicio o de forma-
ción.
• Revisión del ciclo de vida de provisión de peticiones para su optimización.
Identificación de necesidades de provisión. Las peticiones y comentarios.
• Reducción de costes ocultos.
• Describa las etapas de la gestión del incidente en su organización.
• ¿Qué mejoraría para que la resolución de incidentes fuera más efi-
ciente?
• Describa el ciclo de gestión de peticiones en su organización.
1
8.3. Gestión del problema 589
8.3. Gestión del problema
Figura 8.3.1. Actividades principales del proceso de gestión del problema
La gestión del incidente está centrada en “apagar y apagar incendios”, y no debe

perder ni un segundo en resolver la causa que los provoca. Pero si únicamente se
hiciera esto, no se resolverían los defectos y los servicios se volverían a caer una y
otra vez. El personal de soporte tendría cada vez más actividad de “apaga fuegos”
y se pasaría todo el día levantando servicios que volverían a fallar. Para evitarlo se
define un segundo proceso dentro de la categoría de resolución que va por detrás
del proceso de gestión del incidente, eliminando los defectos ya aparecidos en los
componentes de TI. También trabaja buscando los defectos latentes, evitando que
se manifiesten y causen estragos en la funcionalidad prestada al cliente.
Por tanto, la gestión del problema es el proceso que identifica la causa raíz de los
fallos que ocurren o que potencialmente pueden ocurrir en los servicios de TI, al
objeto repararlos para evitar la aparición de nuevos incidentes o la repetición de los
mismos.
Si la gestión del incidente se enfoca en resolver los incidentes, la gestión del pro-
blema se centra en evitar que se produzcan, para lo cual identifica y subsana los
defectos en los componentes de los servicios para aumentar su estabilidad y su ren-
dimiento. Así, se minimiza el impacto negativo que tienen sobre el negocio los
fallos en los elementos de TI y se contribuye a la mejora continua de la infraestruc-

tura que soporta los servicios.
Conviene tener claro que este proceso no interviene en la resolución como tal de
un incidente cuando está abierto. En esta etapa es el proceso de gestión del inci-
dente el único dueño y señor de la situación. La gestión del problema se activará
para identificar y eliminar la causa que provocó el incidente, una vez restaurado el
servicio o de forma paralela a su restauración.
La gestión del problema es uno de los procesos más sencillos de iniciar y que antes
produce resultados, por tanto debe tenerse en cuenta para proporcionar éxitos rápi-
dos (quick-wins).
En su misión de evitar que se produzcan incidentes, el proceso de gestión del pro-
blema trabaja los aspectos reactivos y los proactivos. La parte reactiva trata de
resolver los defectos que ya se han identificado, bien sea por el propio proceso, por
la gestión del incidente, por otros procesos (gestión de nivel de servicio, gestión de
la disponibilidad, gestión de la capacidad, etc.) o bien por otras áreas (desarrollo,
seguridad, soporte técnico, ingeniería, arquitectura, etc.). Mientras que el aspecto
proactivo está relacionado con la búsqueda de los defectos latentes, que no han
aparecido todavía pero que generarán interrupciones en los servicios.
En la figura 8.3.2 se presenta un esquema introductorio al proceso.

del problema • Reduce el número de incidentes.
• Estabiliza el entorno de producción.
Definición: • Asegura la resolución de defectos
graves que afectan al servicio.
La misión del proceso es evitar que se
produzcan incidentes repetitivos o • Identifica la causa raíz de las
nuevos. Para lo cual, identifica y subsana incidencias, evitando su repetición.
los defectos en los componentes de los • Propone proyectos de mejora para
servicios. resolver los defectos.
• Encuentra soluciones provisionales y
Objetivo: permanentes.
Minimizar los efectos negativos sobre • Realizar el seguimiento de la

el negocio de interrupciones del resolución de los problemas
servicio, mediante la identificación identificados.
y el análisis proactivos de la causa • Registra el conocimiento técnico.
de los incidentes y la gestión de los
problemas para su cierre.
Figura 8.3.2. Introducción al proceso de gestión del problema

Los principales beneficios que aporta la gestión del problema son los siguientes:
• Reduce el número de incidentes y, por tanto, mejora la calidad de los servi-
cios.
• Estabiliza los servicios en producción regular para mantener el transcurrir
normal del negocio.
• En su trabajo, encuentra soluciones provisionales y permanentes a los defec-
tos de los servicios.
• Asegura la resolución de defectos graves que afectan al servicio.
• Identifica la causa raíz de los incidentes, evitando incidentes repetitivos.
• Propone proyectos de mejora para resolver los problemas.
• Realiza el seguimiento de los problemas identificados.
• Incrementa el conocimiento de la organización, proporcionando:
– La identificación de tendencias en los datos históricos.
– Los medios para prevenir fallos y para reducir el impacto de los fallos en
el negocio.
– Los errores conocidos, soluciones provisionales y soluciones permanentes
a la base de datos del conocimiento.
– La mejora del ratio de resoluciones de incidentes en el primer contacto o
en la primera línea de atención por el service desk.
Para el éxito del proceso es necesario desplegar tres disciplinas básicas: un buen
conocimiento técnico, una vocación por la calidad técnica y el seguimiento de los
temas hasta que los defectos queden completamente eliminados. En la figura 8.3.3
se muestran estas disciplinas esenciales del proceso.
Tarde o temprano, los defectos latentes acaban saliendo a la luz, generando inci-
dentes en los servicios. En este momento aparece la necesidad de disponer de espe-
cialistas con un buen conocimiento técnico para realizar la investigación a fondo
hasta identificar el defecto y buscar una solución.
El proceso también requiere perseverancia para el seguimiento de todos los temas
hasta su finalización, pues con frecuencia, será necesaria la participación de muchas
áreas técnicas: unas veces habrá que revisar todo un desarrollo, otras los equipos de
comunicaciones, en ocasiones habrá que reemplazar un equipamiento o actualizar
al último parche el software base. Por tanto, el proceso debe controlar múltiples acti-
vidades de resolución de los problemas que transcurrirán en paralelo, actuando
Figura 8.3.3. Bases de la gestión del problema
como coordinador e impulsor de la actividad de otros procesos o grupos de

soporte.
El proceso también requiere una auténtica vocación por la calidad técnica de los
componentes, buscando indicios de defectos latentes y disfrutando con la mejora
paulatina de los servicios. En la vorágine que actualmente existe en el interior de
las organizaciones de TI, mantener una actividad cuyos resultados tengan efectos
en un futuro puede parecer una situación idílica y utópica. Pero las organizaciones
maduras, que ya han implementado la parte proactiva del proceso, obtienen gran-
des beneficios en la estabilidad de los servicios y en la tranquilidad de la organiza-
ción con estas acciones proactivas de mejora técnica continua.
Los principales componentes que son necesarios para el correcto desempeño del
proceso se muestran en la figura 8.3.4.
En ITIL este proceso está dotado de cierta riqueza terminológica para de tener clara-
mente identificadas las fases por las que pasa un problema (problema, error y error
conocido) y los tipos de soluciones (provisional o permanente).
Problema. Conjunto de hechos o circunstancias que dificultan la consecución de
los servicios y provocan incidentes. Es la causa desconocida que origina uno o más
incidentes, existentes o potenciales. Los problemas se pueden identificar a través de
Problema
• Service desk Solución provisional
• Gestión incidente Causa raíz (workaround)
• Gestión disponibilidad CONTROL DE Error
• Gestión capacidad PROBLEMAS
Solución
• Gestión nivel de servicio
Ticket de Error permanente
• Áreas técnicas
problema conocido
• Seguridad (KE)
• Desarrollo
Solicitud de
cambio (RFC)
CONTROL DE
PREVENCIÓN ERRORES
PROACTIVA DE
PROBLEMAS Problema PIR
resuelto Resolución
del error
CMDB BD de problemas
Conocimiento
BD incidentes Base datos Fichas de Errores técnico
configuración problemas conocidos
Figura 8.3.4. Componentes principales del proceso
la aparición de varios incidentes que muestren síntomas comunes. También pueden

identificarse a partir de un incidente de alta relevancia. Otras veces se identificarán
antes de que ocurran incidentes.
Causa raíz. Es el defecto o tara que origina incidentes. Este concepto es impor-
tante, pues a partir de él se divide en dos etapas el ciclo de vida del problema.
Conocer la causa no implica que se conozca la forma de solucionarla.
Error. Un defecto o mal funcionamiento que causa fallos de uno o más elementos
de configuración o servicios TI. Un error cometido por una persona o un desper-
fecto en un proceso que impacta un CI o un servicio TI es también un error. Un
problema pasa a la categoría de error cuando se ha identificado la causa raíz que
originó el problema y origina el paso a la segunda fase del proceso (control de
errores).
Error conocido (KE, Known Error). Es un error para el que, además de cono-
cerse cuál es la causa raíz que lo originó, se ha diseñado o definido también la o las
formas de resolverlo, mediante una solución provisional o una solución perma-

nente. El error conocido se trata como una unidad de información específica y se
registra mediante una ficha que contiene el conocimiento sobre su resolución. Los
errores conocidos se registran por el propio proceso de gestión del problema, pero
también pueden ser dados de alta por otros actores externos al proceso, general-
mente se tratará de otras áreas de índole técnico, como por ejemplo, infraestructu-
ras, seguridad, desarrollo, etc.
Solución provisional o workaround. Es la solución temporal a un error con el fin
de restaurar rápidamente un servicio. Las soluciones provisionales no eliminan o
resuelven la causa raíz (véase el apartado 8.1 Antecedentes). Los workaround se
crean en diversos ámbitos, por ejemplo, en el proceso de gestión del incidente para
la restauración del servicio, en el propio proceso de gestión del problema y tam-
bién pueden ser originados por el equipo de desarrollo debido a fallos identificados
en la aplicación durante las pruebas de certificación. La gestión del problema
deberá tratar de eliminar estos “parches” en los servicios para implantar soluciones
permanentes.
Solución permanente. Es el conocimiento de la forma de erradicar definitiva-
mente la causa raíz que dio origen al fallo, como por ejemplo, mediante mejoras en
la infraestructura. Las soluciones permanentes son identificadas por el proceso de
gestión del problema, pero las construyen las áreas de desarrollo o de infraestructu-
ras, las autoriza la gestión del cambio y las implementa la gestión de la entrega.
Resumiendo toda esta secuencia semántica, importante para conocer el proceso:
un problema latente se manifiesta y provoca incidentes, por lo que pasa a la catego-
ría de problema (no se conoce la causa pero se sabe que hay algo que está provo-
cando incidentes). Investigando el problema se encuentra la causa raíz que lo ori-
ginó, por lo que el problema pasa a estado de error. En el momento en el que se le
encuentra una forma de solucionarlo, el error se convierte en un error conocido.
Las soluciones pueden ser provisionales o permanentes.
Ticket de problema. Ficha o registro que contiene los datos asociados a un pro-
blema. El soporte del registro no es obligatorio que sea electrónico, aunque es reco-
mendable por su facilidad de utilización.
Base de datos de problemas. Repositorio que contiene información necesaria
para el proceso de gestión del problema. Está divida en dos partes lógicas: la fichas
de problemas y los registros de errores conocidos.
Conocimiento técnico. Diversas fuentes de conocimiento técnico existentes,
como por ejemplo, las generadas por la organización de TI, de los fabricantes, etc.
Clasificación de un problema. Al igual que ocurre con los incidentes y con los
cambios, es necesario clasificar un problema para determinar inicialmente el grupo
de resolución al que asignarlo y el orden de ejecución. La clasificación de los pro-

blemas sigue los mismos criterios que los utilizados para incidentes: se asigna una
categoría (hardware, software, etc.) y una prioridad (en función del impacto y de la
urgencia).
La clasificación del problema puede variar a lo largo de la vida del problema, según
se vaya avanzando en su conocimiento, desde los indicios iniciales hasta su resolu-
ción. La clasificación de un problema permitirá a otros procesos acceder al conoci-
miento de los errores conocidos de forma precisa, mientras que la prioridad permi-
tirá identificar los problemas a resolver en primer lugar.

En una organización grande, la cantidad de problemas abiertos suele rondar entre
100 y 200 tickets al mes, al contrario que en incidentes y peticiones que suele osci-
lar entre 10.000 y 30.000 al mes. El número de tickets de problemas es de un orden
de magnitud cien veces inferior al de incidentes. Por ello, la implantación de la ges-
tión del problema es organizativamente mucho más sencilla, muy centrada en acti-
vidades de investigación técnica y análisis.
Las funcionalidades que se deben desarrollar en la gestión del problema se resumen
en el esquema de la figura 8.3.5.
La entrada principal que activa el proceso es la recepción de tickets de problemas
por parte del service desk, de la gestión del incidente, de la gestión de la disponibili-
dad, de la gestión de la capacidad, de la gestión de nivel de servicio, etc. Otras
entradas que desencadenan el proceso son los fallos y sus soluciones provisionales
o workarounds aplicados, y la información de defectos en los productos proporcio-
nada por los proveedores. También es importante tener en cuenta que actores exter-
nos al proceso de gestión del problema (pertenecientes generalmente a otras áreas
como desarrollo, seguridad o infraestructuras) pueden generar errores conocidos
que entran directamente en la mitad del proceso, en el control de errores. Otra
entrada que identifica problemas puede ser la revisión proactiva o diaria de los dis-
tintos elementos del servicio; por ejemplo, un grupo responsable de la administra-
ción de bases de datos, mediante las revisiones diarias de las mismas, pueden iden-
tificar posibles problemas que aún no han desencadenado incidencias.
El proceso utiliza también entradas de soporte que aportan la información necesaria,
como por ejemplo, la información de los incidentes procedente de la base de datos
de incidentes, la información sobre los componentes de los servicios desde la base de
datos de gestión de la configuración (CMDB), su comportamiento y su relación con
los niveles de servicio comprometidos con los clientes, el conocimiento técnico de la
Desencadenantes REACTIVAS: Salidas principales:

del proceso: 3 Control de problemas Ü Problemas resueltos.
Ü Tickets de problema (buscar la causa raíz). Ü BD de problemas, con
desde service desk, 3 Control de errores los errores conocidos:
otros procesos y otras (diseño de la solución y Ü Soluciones provisionales.
áreas. resolución definitiva). Ü Soluciones permanentes.
Ü Fallos y sus
workarounds aplicados. Ü RFC a gestión del
PROACTIVAS: cambio.
Ü Información de
productos de los 3 Revisión de problemas
importantes. Salidas secundarias:
fabricantes.
3 Prevención proactiva Ü Notificación de
Ü Errores conocidos
de problemas (identificar resolución del ticket
identificados por
posibles problemas). de problema
otras áreas ajenas
(a incidentes, etc.).
al proceso.
3 Supervisión y mejora del Ü Base de datos de
Ü Revisión proactiva de
proceso. incidentes.
los elementos del
servicio. Ü Modificaciones en la
CMDB.
Entradas de soporte: Ü Información gestión y
Ü BD de incidentes. costes.
Ü CMDB. Ü Propuestas de mejora.
Ü Conocimiento técnico.
Ü Estado del RFC desde
gestión del cambio.
Fuente: e.p., libro ITIL Soporte de Servicio publicado por OGC y Telefónica.
organización o de los fabricantes, la situación de evolución de las peticiones de cam-

bio emitidas para la erradicación de los problemas, etc.
Las actividades principales del proceso son las siguientes:
• Control de problemas (buscar la causa raíz). Se ocupa de la identificación,
registro, clasificación y seguimiento de los problemas, llevando a cabo la
investigación y diagnóstico de su causa raíz. Al finalizar la etapa, el problema
alcanza el estado de “error”, es decir, se conoce su causa raíz. En la actividad
de investigación de la causa raíz también se identifican las diversas vías de
solución, que servirán de entrada al control de errores. Si se ha descubierto
también la forma de resolverlo se alcanza directamente el estado “error cono-
cido” y se pasa directamente a la etapa de control de errores.
• Control de errores (diseño de la solución y su resolución definitiva). Esta

fase parte de un error, generado en la etapa anterior, para después valorar la
idoneidad de la alternativas de solución, diseñar la más adecuada y gestionar
su construcción e implementación.
Mientras que el control de problemas se centra en la búsqueda de la causa
raíz, el control de errores se centra en su resolución definitiva.
• Revisión de problemas importantes. Es necesario que en los problemas
ocurridos con trascendencia o con un impacto alto en el negocio, se lleve a
cabo una revisión de lo ocurrido, para proponer mejoras en las infraestructu-
ras, en las formas de actuación de las personas o en la propia organización.
• Prevención proactiva de problemas (identificar posibles problemas). Tiene
como objetivo la prevención de los posibles problemas antes de que ocurran,
analizando las tendencias e identificando componentes débiles o sobrecargados.
• Supervisión y mejora del proceso. Conjunto de actividades ligadas que
tiene como objetivo que el proceso funcione a la perfección mediante la
supervisión de su funcionamiento y la identificación de actividades para
la mejora continua. Para ello se debe:
– Capturar indicadores que permitan medir el proceso, puesto que “no se
puede mejorar lo que no se puede medir”.
– Verificar el grado de cumplimiento del proceso establecido mediante la
realización de auditorías periódicas.
– Monitorizar el proceso realizando el control y seguimiento de los proble-
mas y errores a lo largo de todo su ciclo de vida.
– Evaluar los resultados obtenidos y de forma consensuada con los respon-
sables de otros procesos afectados, identificar planes de mejora.
Las salidas principales del proceso de gestión del problema son los problemas
resueltos y la base de datos de problemas, que contiene los errores conocidos con
sus soluciones provisionales y permanentes. La información sobre los errores cono-
cidos es una fuente importante de conocimiento, a veces se considera una base de
datos independiente de los errores conocidos, y es esencial para que el proceso
de gestión del incidente diagnostique y resuelva con rapidez. También es una salida
principal las peticiones de cambio (RFC) generadas para la construcción e imple-
mentación de las soluciones (provisionales o permanentes) encontradas.
Otras salidas de índole secundario son la notificación sobre la evolución o resolución
del problema a quién generó el ticket del problema; la base de datos de incidentes
actualizada con las causas raíces identificadas, con las soluciones provisionales o
ermanentes encontradas a estos incidentes; la actualización de la CMDB con infor-

mación sobre los defectos encontrados en los elementos de configuración y sus solu-
ciones; información de gestión del proceso, de sus costes y de las valoraciones
de costes asociados a la investigación y resolución de problemas; o las propuestas de
mejora de las infraestructuras o de los procesos, encontradas a lo largo de la activi-
dad del proceso.
Alcance de la gestión del problema
UNE-ISO/IEC 20000-2
El proceso de gestión del problema ción o la duplicación de los incidentes o

debería investigar las causas subyacen- de los errores conocidos de acuerdo
tes de los incidentes. con los requisitos del negocio.
La gestión del problema debería preve-
nir de una manera proactiva la repeti-
La gestión del incidente y la gestión del problema tienen dos objetivos claramente
diferenciados. Mientras el primero debe recuperar el servicio lo antes posible, el
segundo se ocupa de que ese tipo de incidente no se reproduzca.
También en los métodos de ejecución actúan de forma diferente. Mientras la gestión
del incidente trabaja en una carrera contrarreloj para lograr obtener la recuperación
del servicio en tiempo récord; la gestión del problema trabaja, normalmente a medio
plazo, para erradicar la causa raíz con independencia del cierre o no del incidente.
La gestión del problema requiere un esfuerzo nada despreciable, tanto económico,
como de apoyo de la dirección, ya que el equipo de resolución de problemas, a
menudo experto en la tecnología afectada, debe liberarse del día a día. Así, se nece-
sita el soporte de la dirección para la dedicación de estos recursos y mantenerlos,
aunque en ocasiones los plazos de resolución se prolonguen.
También, el proceso debe velar por que el ratio coste (de investigación y de resolu-
ción) frente al beneficio (por la eliminación de los incidentes) sea óptimo.
A la hora de iniciar la implementación del proceso se recomienda poner primero
foco en resolver los problemas que se produzcan en los servicios vitales para el
negocio, para ir extendiendo paulatinamente su cobertura al resto de servicios
menos críticos. En etapas posteriores se incorporarán las actividades proactivas,
para identificar los problemas latentes antes de que generen incidentes.
Por otra parte, la eficacia de este proceso sólo podrá obtenerse, tras disponer de un pro-
ceso de gestión del incidente suficientemente maduro, que registre toda la información
necesaria (clasificación, síntomas, resolución, etc.) para poder actuar a posteriori.
También es conveniente disponer de buenos sistemas de monitorización tecnoló-
gica, correlación de eventos y análisis de estadísticas.
Ciclo de vida de un problema

De forma similar a la gestión del incidente, las actividades repetitivas de este pro-
ceso se pueden agrupar bajo el concepto de ciclo de vida del problema, teniendo en
cuenta que este proceso no gestiona grandes volúmenes de actividad, ya que es un
proceso centrado en la investigación profunda y tenaz. En la figura 8.3.6 se pre-
senta un esquema de este ciclo.
Figura 8.3.6. Actividades del ciclo de vida de un problema

El ciclo de vida de un problema se estructura en dos etapas o subprocesos: el con-

trol de problemas y el control de errores.
Control de problemas
La etapa de control de problemas es la primera que se activa cuando se detecta un
problema, se inicia con la recepción del ticket del problema y concluye con la iden-
tificación de la causa raíz del mismo. El ticket entra en estado de problema y sale en
estado de error.
UNE-ISO/IEC 20000-1
Se deben registrar todos los problemas identificados.

Se deben adoptar procedimientos para identificar, minimizar y evitar el impacto de
los incidentes y de los problemas. Estos procedimientos deben definir el registro, la
clasificación, la actualización, el escalado, la resolución y el cierre de todos los pro-
blemas.
UNE-ISO/IEC 20000-2
Se deberían clasificar los incidentes Nota: Cuando se registren incidentes por primera
para ayudar a determinar las causas de vez, su categorización se verá influenciada
por otros factores que incluyen el servicio,
los problemas. La clasificación puede
el área de negocio afectada y los síntomas
hacer referencia a los problemas y cam- que se presenten.
bios existentes.
Al igual que en los incidentes, todo problema debe estar previamente registrado. Si
este proviene de un incidente, se deben establecer referencias cruzadas entre ambos.
Las actividades comprendidas en la etapa de control de problemas son:
Identificación y registro de problemas. La identificación de los problemas proviene
de distintas fuentes de la organización de TI, ya sea de forma reactiva o proactiva:
• Del service desk y de la gestión de incidentes.
• De problemas propuestos a partir del análisis de eventos de las herramientas
de monitorización de la infraestructura desde la gestión de eventos.
• De problemas asociados a los servicios detectados en la gestión de nivel de
servicio.
• Del análisis de tendencias realizada por la faceta proactiva del proceso.

• Del análisis de las encuestas, las quejas y las sugerencias de los usuarios, que
pueden revelar también posibles problemas.
• Las reuniones con los clientes y las encuestas, pueden también llevar a la
identificación de las tendencias y de las áreas de problemas (potenciales).
Cuando se ha identificado un problema, se genera un ticket o ficha de problema,

con los datos identificativos del mismo. Estos tickets se registran en la base de datos
de gestión del problema. A lo largo de la vida del problema se irá actualizando y
enriqueciendo la información registrada. Un ejemplo de contenido del ticket o ficha
de problema se muestra en la figura 8.3.7. Los registros de problemas deben estar
asociados con todos los registros de los incidentes que resuelven.
Ticket o ficha de un problema
3 Número de ticket.
3 Persona que abrió el problema.
3 Fechas: apertura, actualizaciones, cierre.
3 Estado del problema.
3 Datos descriptivos del problema:
• Descripción.
• Detalles.
• CI implicados. Servicio o aplicación.
• Categoría.
• Prioridad (impacto+urgencia). Esto ayudará a
• Incidentes asociados. tener documentado
el problema más
3 Historial del problema: escalados, participantes,
detalladamente y
descripción de las investigaciones realizadas, etc.
dará pistas a posibles
3 Datos descriptivos de la resolución: investigaciones para
• Descripción de la solución provisional. solucionar otros
• Descripción de la solución definitiva. problemas.
• RFC generados, sus fechas y sus estados.
• Fecha de cierre.
3 Revisión del problema
• Esfuerzo y costes necesarios para la resolución.
• Beneficio aportado.
Figura 8.3.7. Ejemplo de ficha de un problema

Una buena clasificación de los incidentes es esencial para extraer información pre-
cisa para la identificación de problemas.
Por otra parte, las soluciones generadas por incidentes se deberían almacenar tam-
bién en la base de datos de problemas, para que el conocimiento se centralice en un
único punto.
Clasificación de problemas. Al igual que los incidentes y los cambios, los proble-
mas deben tener también asignada una categoría y una prioridad (en función del
impacto y urgencia) para poder planificar los recursos adecuadamente.
Es importante que la asignación de una categoría a los problemas sea precisa y bien
realizada, para poder asignar el problema a los equipos de soporte adecuados y,
para una vez resuelto, poder acceder con precisión al conocimiento. La clasifica-
ción de un problema se va depurando según avanza la investigación sobre el
mismo.
Con relación a la prioridad, se necesita que se asigne una a cada problema y aun-
que el volumen de problemas puede ser bajo, el número de recursos asignados a la
gestión de los problemas también suele ser escaso, por lo que disponer de un orden
de ejecución resulta nuevamente fundamental. En la definición del impacto se
estima la criticidad de los servicios que se verían afectados si el problema provocase
un incidente, el número de servicios, el volumen de usuarios amenazados, etc. La
urgencia se determina en función de la probabilidad de que se puedan producir
incidentes.
Los problemas tienen también un estado según avanzan en su ciclo de vida, para
tener un mayor control del proceso y poder realizar análisis estadísticos posteriores.
En la figura 8.3.8 se muestra un ejemplo de algunos detalles relevantes del proceso.
Investigación y diagnóstico de problemas. Los problemas se gestionan de forma
centralizada por el proceso, pero en su investigación y resolución se asignan a los
especialistas de TI, denominados analistas técnicos (propietarios de los elementos
de configuración involucrados en el problema, técnicos de las áreas afectadas,
equipo de desarrollo, responsables del servicio afectado, etc.). En la investigación,
con frecuencia se necesita también la participación de los fabricantes.
El analista técnico de problemas asignado realiza la investigación y diagnóstico con
los medios a su alcance para identificar la causa raíz del problema. Si a lo largo de
esta actividad surgen conflictos por la necesidad de dedicación de recursos, se lo
comunicará al responsable del proceso, de modo que éste pueda tomar las acciones
correctoras necesarias.
Tradicionalmente en este punto de la investigación se describen varias técnicas
genéricas que ayudan al análisis en las tareas de investigación y diagnóstico.
Detalles relevantes de un problema
Estados de un problema Clase Subclase
Nuevo Hardware Instalación

Configuración
Clasificado
Factor humano
Asignado Funcionalidad
En diagnóstico Software Inconsistencia
Rendimiento
Error
Bloqueo
Error conocido
Desconocido
En resolución
Solucionado
Cerrado
Prioridad de un problema
IMPACTO
PRIORIDAD
Alto Medio Bajo
Se
Alta rvi
cio
sv
ita
URGENCIA
Pro les
bab , vo
ilid lum
Media ad en
de de
pro usu
duc ari
ir i os,
nci etc
Baja den .
tes
Figura 8.3.8. Ejemplo de detalles relativos a la clasificación de un problema
• El método de análisis de Kepner y Tregoe, sistematiza en 5 pasos el análisis

de los problemas:
1. Definición del problema.
2. Descripción del problema (identidad, emplazamiento, tiempo y tamaño).
3. Establecer las posibles causas.

4. Probar la causa más probable.
5. Verificar la causa verdadera.
• La técnica de análisis causa–efecto de Ishikawa que plantea sobre un

esquema horizontal, de izquierda a derecha, en forma de raspa de pescado
las posibles causas y los efectos que producen.
• La técnica estadística de Pareto, permite centrarse en el 20% de los proble-
mas esenciales, que resolverían el 80% de los incidentes. Sirve más para fil-
trar y priorizar problemas que para investigar o diagnosticarlos
La actividad de investigación y diagnóstico de problemas es muy similar la de

investigación de incidentes, pero el objetivo primordial en cada caso es distinto. El
primero busca el diagnóstico de los defectos subyacentes, mientras que el segundo
se centra en la restauración rápida del servicio. El objeto de la investigación es pro-
porcionar un diagnóstico del problema encontrado su causa raíz. Diagnosticada la
causa raíz, el problema pasa al estado de “error”. La investigación también debe
identificar las posibles soluciones para eliminar o paliar los efectos de la causa raíz.
Este abanico de soluciones servirá de entrada a la fase de control de errores.
La causa de un problema puede ser debida un error en la actuación humana (por
ejemplo, la instalación de una versión incorrecta, olvido de cambiar algún paráme-
tro de configuración, etc.) y no sólo ocasionada por un defecto en un componente.
En estos casos, el problema se resuelve corrigiendo la equivocación (que también
puede requerir una petición de cambio) y no es necesario generar una “solución
permanente”, pero si es necesario registrar la solución aplicada a efectos de mejora
del proceso.
Control de errores
El control de errores se encarga de subsanar los errores y eliminar las causas raíces
que los provocan. Realiza el seguimiento de todos los errores conocidos, desde su
identificación hasta su resolución.
UNE-ISO/IEC 20000-2
Cuando la investigación de la gestión para resolver los incidentes, el pro-

del problema haya identificado la causa blema se debería clasificar como un
del origen de un incidente y un método error conocido.
Se deberían registrar todos los errores Un error conocido no se debería cerrar

conocidos tomando como referencia los hasta que se haya resuelto satisfactoria-
servicios real o potencialmente afecta- mente.
dos además del elemento de configura-
Nota: El cliente o el proveedor del servicio pue-
ción que se sospeche que causa el error den decidir que la resolución resulta
en cuestión. demasiado cara o que no aporta beneficio
al negocio. En este caso, esto debería
La información sobre los errores conoci- quedar claramente documentado. No obs-
dos en los servicios que se estén intro- tante, el error conocido debería permane-
duciendo en el entorno productivo se cer abierto, puesto que aún existe la posi-
debería pasar a la gestión del servicio y bilidad de que se produzcan incidentes a
consecuencia de este error y es posible que
se debería registrar en la base de datos se necesiten soluciones provisionales y/o
de conocimiento, junto con las solucio- una reconsideración de la decisión para
nes provisionales existentes. resolver el error.
Las Normas ISO/IEC 20000 ponen foco en la responsabilidad de gestión del pro-
blema como generador y difusor del conocimiento sobre los errores conocidos. Los
errores conocidos se almacenan en una base de datos, típicamente como un sub-
conjunto integrado en la base de datos de gestión del problema, y se ponen a dis-
posición de otros procesos en modo de sólo lectura. Por otra parte, la gestión del
incidente mantiene la base de datos de incidentes en la que se registra todo lo que
se analiza e identifica en la resolución del incidente. Por tanto, las bases de datos de
problemas y de incidentes son complementarias.
Además, los instrumentos, más utilizados en la resolución de incidentes son el
árbol de tipologías de incidentes, la base de datos de incidentes, con la resolución
de incidentes similares, y la base de datos de problemas, en su vista de los errores
conocidos.
Por ello, la coordinación aquí es muy importante ya que se debe aportar coherencia
y consistencia a las clasificaciones de cada elemento. Muchas veces, aparecen árbo-
les de tipologías (propiedad del proceso de incidentes), que simulan la lista de erro-
res conocidos (propiedad de gestión del problema), que se solapan y confunden al
técnico de soporte de primer nivel.
Identificación y registro de errores. En el proceso los errores se tratan como una
estructura de información específica, por ello, la primera actividad de la etapa de
control de errores es la identificación y el registro de los mismos.
Valoración de errores. En esta actividad se realiza una evaluación de los recursos y
plazos necesarios para las alternativas de solución. En la evaluación se contrasta el
coste con los beneficios y la situación actual de la organización, para determinar si

se lleva a cabo su resolución.
Puede ocurrir que el coste de resolución de un problema o el esfuerzo requerido
no compense o justifique su realización. Como se aprecia en el ejemplo de un caso
real en el que una aplicación de recursos humanos para el autoservicio de los
empleados, de uso poco intensivo, montada sobre una arquitectura web de tres
capas y que se bloqueaba esporádicamente varias veces al día. El equipo de proble-
mas identifica e implanta primero una solución provisional, mediante un programa
(o cron) que supervisa continuamente el funcionamiento del servidor web, que
cuando se bloquea lo reinicia. Así, el bloqueo dura un minuto escaso. Se contacta
con el fabricante, que informa que para resolverlo es necesario actualizar a la última
versión el producto base. Pero esto conlleva un coste alto, pues es necesario revisar
todo el aplicativo y la parametrización del producto base. Dado que la solución
provisional permite salir temporalmente del paso, se decide no resolverlo definiti-
vamente hasta que por necesidades funcionales sea necesario realizar una actualiza-
ción de versión de esta plataforma.
Registro de la resolución del error (investigación de la solución y lanzamiento
de la RFC). En este momento se realiza la investigación detallada para encontrar o
diseñar la solución permanente. La identificación de la causa raíz y el conocimiento
de la solución permanente a aplicar, en muchos casos no implica que se tenga dis-
ponible el nuevo componente a cambiar, que se haya adquirido el producto o que
se tenga ya el desarrollo modificado. Para la construcción de la solución perma-
nente, se genera una petición de cambio (RFC) para que el proceso de gestión del
cambio apruebe la construcción de la solución por las áreas adecuadas (desarrollo o
infraestructuras). Una vez construida la solución, el proceso de gestión de la
entrega se encargará de su implementación.
UNE-ISO/IEC 20000-1
Se deben remitir al proceso de gestión del cambio los cambios necesarios para
corregir la causa subyacente de problemas.
UNE-ISO/IEC 20000-2
Cuando la causa raíz se haya identifi- debería conducir a través del proceso
cado y se haya tomado una decisión de gestión del cambio.
para resolver el error, la resolución se
En el momento en que se conoce una solución provisional o permanente, el error

pasa al estado de “error conocido”. El conocimiento completo sobre el error cono-
cido se almacena en la vista o base de datos de errores conocidos.
También existen otras fuentes de errores conocidos generados desde otras áreas,
como por ejemplo, la información de los fabricantes, la información desde el
ámbito de seguridad en cuanto a nuevas vulnerabilidades y, muy frecuentemente,
los que llegan desde el desarrollo de aplicaciones. Estos errores conocidos se regis-
tran directamente en la base de datos de errores conocidos.
Cierre de errores (y revisión postimplementación). Enviada la petición de cam-
bio para la construcción de la solución, desarrollada e implementada, el proceso de
gestión de la entrega realiza la primera revisión postimplementación (PIR, Post
Implementation Review) de cambios para comprobar que la solución se ha implan-
tado con éxito. Este hecho se comunica a la gestión del cambio, que registra el PIR
y cierra el cambio. La gestión del cambio comunica a control de errores que su
cambio se ha implementado con éxito, que comprueba (PIR de problemas)
durante un período que no se vuelven a producir incidentes y se asegura que la
reparación ha sido efectiva. Esta comprobación, en el caso de problemas menores,
puede reducirse a un contacto con el usuario para comprobar que todo va correcta-
mente. En el caso de problemas graves es necesaria una revisión formal.
UNE-ISO/IEC 20000-2
El procedimiento de cierre del registro soporte estén al corriente de la

debería incluir comprobaciones para resolución;
garantizar que: d) el cliente acepte que la resolución
a) los detalles de la resolución se se ha conseguido;
hayan registrado con precisión; e) el cliente sea informado si no se
b) la causa esté categorizada para va a llegar a una resolución o
facilitar el análisis; ésta no resulta posible.
c) si es necesario, tanto el personal
del cliente como el personal de
En el cierre, las mejores prácticas indican que:

• No solamente se debe contemplar que el cambio ha culminado con el éxito
que certifica su revisión postimplementación (PIR de cambios).
• Sino que, también se revisa desde el proceso de gestión del problema que los
incidentes no se reproducen (PIR de problemas), normalmente pasado un
tiempo prudencial, que variará según las estadísticas de análisis de problema

y su temporalidad.
• Y que también, una vez subsanado el error conocido, se deshacen todos los
workarounds o soluciones provisionales que se realizaron para mantener dis-
ponible la infraestructura afectada, saneándola y dejándola en optimas condi-
ciones (por ejemplo, quitando el cable auxiliar que se había tendido fuera de
su canalización, eliminando el programa cron que reiniciaba el servicio, etc.).
Resumiendo, mientras el PIR de cambios certifica que el cambio y la entrega han

sido satisfactorios según las especificaciones constructivas originales, el segundo
PIR de problemas constata que los incidentes no se han vuelto a repetir, y se puede
dar por concluido el caso o problema.
En el cierre del error y del problema se revisan la documentación sobre el error
conocido y la solución permanente, y se documenta con el detalle suficiente para
que la primera línea de soporte pueda implementarla o pedir que se implemente.
El registro de error conocido se cierra, junto con el del problema y el de los inci-
dentes relacionados.
Se añade a la información del cierre un breve estudio del retorno de la inversión
efectuado en la resolución del problema, en términos de ahorro del lucro cesante
en términos económicos, que el negocio entienda y que también documentarán de
manera tangible los beneficios del proceso.
Comunicación y conocimiento
Las Normas ISO/IEC 20000 recomiendan que se comunique a las partes interesa-
das las soluciones provisionales, permanentes y el progreso de la resolución del pro-
blema. Pero la faceta de comunicación del proceso va más allá, proporcionando una
base de conocimiento de errores conocidos muy importante a la organización en
general y especialmente a la gestión del incidente. Además, presenta informes a la
dirección y a otros procesos sobre la evolución de su actividad, y especialmente al
centro de servicio al usuario.
UNE-ISO/IEC 20000-1
Para que resulte eficaz la resolución de problemas, se debe supervisar, revisar y ela-
borar informes sobre ella.
El equipo de gestión del problema debe ser responsable de garantizar que esté dis-
ponible, para la gestión de incidentes, la información actualizada sobre errores
conocidos y problemas corregidos.
UNE-ISO/IEC 20000-2
La información sobre soluciones provi- comunicar a las partes afectadas o

sionales, arreglos permanentes o el pro- puede requerirse para dar soporte a los
greso de los problemas se debería servicios afectados.
Es una buena práctica poner a disposición libre de todo el personal técnico todas las
soluciones de errores, tendencias, previsiones y el resto de conocimiento que desde
gestión del problema se genere. Y también lo es, aprovechar el feedback que, ante
dicho conocimiento, propongan los colaboradores de los equipos de soporte técnico.
Seguimiento y escalado de problemas y errores

De forma transversal a todo el proceso se debe desarrollar la actividad de segui-
miento de los problemas y errores, y su escalado a otras áreas o a la dirección para
obtener el respaldo adecuado. En la función de seguimiento se generan informes
sobre la evolución del proceso, contrastándolo con los acuerdos de nivel de servicio.
UNE-ISO/IEC 20000-2
Se debería realizar un seguimiento del c) la distribución de información en

progreso de todos los problemas. cascada a los clientes y colegas
para que puedan llevar a cabo las
Todos los problemas se deberían esca-
acciones adecuadas para minimi-
lar a las partes apropiadas. El proceso
zar la repercusión del problema no
debería cubrir:
resuelto;
a) el registro de los cambios de las
d) la definición de los puntos de esca-
identidades de los responsables de
lado;
la resolución de problemas durante
el ciclo de vida de cada problema; e) el registro de los recursos emplea-
dos y de las acciones realizadas.
b) la identificación de incidentes que
rompan los objetivos del nivel de
servicio;
Durante el ciclo de vida del problema, se debe registrar información para poder
realizar el seguimiento y escalado. A veces no es sencillo descubrir al inicio del
registro del problema todos los actores que van a acabar trabajando en él. Por esto
se debe alimentar constantemente el registro del caso, con todos los implicados y
sus aportaciones. Como en un análisis forense, cualquier prueba que sea subesti-
mada en una parte del proceso puede ser vital para el esclarecimiento del caso. En
un problema pasa lo mismo; todos los elementos son vitales para la determinación
de la causa raíz.
Revisión de problemas importantes

Una vez finalizada la resolución de un problema importante, el proceso de gestión
del problema debe realizar una revisión del mismo con el fin de identificar lo que
se realizó bien, los errores de actuación, las mejoras y la forma de evitar que vuelva
a ocurrir un problema de este tipo.
UNE-ISO/IEC 20000-1
Las acciones de mejora identificadas durante este proceso se deben registrar e

incluir en el plan de mejora del servicio.
UNE-ISO/IEC 20000-2
Se deberían realizar revisiones de los pro- de problemas respecto a los nive-

blemas siempre que, la investigación para les de servicio;
esclarecer los problemas no resueltos, no
b) revisiones de la dirección para
habituales o de gran repercusión, las justi-
resaltar los problemas que requie-
fique. La finalidad de estas revisiones es
ren una acción inmediata;
encontrar mejoras para el proceso y evitar
la repetición de incidentes o errores. c) revisiones de la dirección para
determinar y analizar tendencias y
Las revisiones de problemas son nor-
para proporcionar información a
malmente:
otros procesos como, por ejem-
a) revisiones de los niveles de inci- plo, el de educación y formación
dentes individuales y del estado del cliente.
En ISO/IEC 20000-2 se detallan los temas que se deben tratar en las revisiones de
los problemas importantes.
UNE-ISO/IEC 20000-2
Las revisiones deberían incluir informa- f) el compromiso del personal para

ción de: resolver los incidentes y los pro-
a) tendencias, por ejemplo, proble- blemas;
mas e incidentes recurrentes, erro- g) repetición de incidentes o proble-
res conocidos, etc.; mas ya resueltos.
b) problemas recurrentes de una Las mejoras del servicio o del proceso
determinada clasificación de de gestión de problemas se deberían
componente o de ubicación; registrar e incluir en un plan de mejora
c) deficiencias causadas por la sub- del servicio.
contratación, la formación o la La información se debería añadir a la
documentación; base de conocimientos de gestión de
d) no conformidades, por ejemplo, problemas.
conforme a normas, políticas y Toda la documentación relevante se
leyes; debería actualizar, por ejemplo, las
e) errores conocidos en las entregas guías del usuario y la documentación
planificadas; del sistema.
Todas las acciones de mejora identificadas a lo largo del proceso de gestión del pro-
blema, tanto técnicas (causas raíz detectadas) como organizacionales, constituye
información importante para aportar al plan de mejora del servicio (SIP, véase el
apartado 6.1) o al plan de mejora unificado de los procesos y de los servicios (véase
el capítulo 4).
Prevención proactiva de problemas

La gestión del problema tiene un componente denominado reactivo muy impor-
tante, tratado anteriormente. Pero no hay que olvidar su otra faceta proactiva, que
quizá es la que más contribuya a la evitar incidentes graves. Las actividades proacti-
vas se centran en identificar defectos o problemas subyacentes antes de que provo-
que incidentes.
UNE-ISO/IEC 20000-1
Se deben llevar a cabo acciones preventivas para reducir los problemas potenciales,
por ejemplo las derivadas de análisis de tendencias de volúmenes y tipos de incidentes.
En ISO/IEC 20000-2 se establece un alcance bastante amplio para la gestión pro-

activa, que comprende desde la prevención de problemas individuales, pasando por
la toma de decisiones estratégicas de cambio, hasta las acciones de formación a los
usuarios y clientes sobre el uso de los servicios.
UNE-ISO/IEC 20000-2
La gestión proactiva de problemas dentes individuales, tales como las difi-

debería conducir a una reducción de los cultades reiteradas para utilizar una
incidentes y de los problemas. Debería determinada función de un sistema,
incluir referencias a la información que hasta las decisiones estratégicas. Es
resulte de ayuda para el análisis como, probable que estas últimas requieran
por ejemplo: un gasto de implementación considera-
ble, por ejemplo, la inversión en una
a) activos y configuración;
red mejor; a este nivel, la gestión del
b) gestión del cambio; problema proactiva se funde con la
c) un error conocido y divulgado, gestión de la disponibilidad.
información sobre las soluciones La prevención de problemas también
provisionales de los proveedores; incluye el suministro de información a
d) información histórica sobre pro- los clientes para evitar que tengan que
blemas similares. pedir ayuda en el futuro, por ejemplo,
para prevenir incidentes causados por
La prevención de problemas debería la falta de conocimiento o la falta de
abarcar desde la prevención de inci- formación del usuario.
En ITIL se establece que las actividades principales de los procesos de gestión pro-
activa de problemas son el análisis de tendencias y la identificación de acciones pre-
ventivas.
Análisis de tendencias. El objetivo es identificar componentes frágiles en la
infraestructura de TI e investigar las razones de esta fragilidad. Así, los informes
sobre el análisis de incidentes y problemas proporcionan información sobre medi-
das proactivas. El análisis de tendencias puede llevar a la identificación de defectos
en la infraestructura de TI y también puede llevar a identificar áreas que necesita-
rán más atención del área de soporte.
Identificación de acciones preventivas. Como consecuencia de la actividad ante-
rior se identifican acciones preventivas que de deben implementar e integrar en el
plan de mejora del servicio (SIP) o en el plan de mejora unificado de los procesos y
de los servicios. Debería ser posible establecer comparaciones significativas expre-
sándolas en términos de costes financieros para la organización.

Aunque resulte paradójico, el propio proceso de gestión del problema encargado
de identificar defectos en los servicios, también debe realizar una labor de “auto-
mejora” de su propia actividad, identificando la utilización excesiva de recursos,
demoras, problemas con la asignación de personal técnico, etc.
Todas las acciones de mejora del propio proceso identificadas no se implementan
sin una coordinación global, por ello, deben integrarse en el plan de mejora unifi-
cado de los procesos y de los servicios (véase el capítulo 4).

Las métricas del proceso deberían facilitar una visión del rendimiento del proceso:
los recursos y esfuerzo utilizados en la investigación, diagnóstico y resolución de
los problemas y errores conocidos. Además, es importante que se proporcione una
visión del estado de los trabajos y de los resultaos obtenidos. También son impor-
tantes los indicadores de resultados sobre la mejora de la calidad de los servicios.
Algunas métricas relevantes del proceso pueden ser las siguientes:
• Número medio de incidentes resueltos por los errores conocidos.
• Número de problemas abiertos y cerrados en el período.
• Número total de errores conocidos existentes en la base de datos de pro-
blemas.
• Número de RFC generadas proactivamente desde gestión de problemas.
• Promedio del coste en resolver un problema.
• Tiempo medio en resolver un problema.
• Tiempo medio empleado en diagnosticar problemas.
• Porcentaje de problemas no diagnosticados.
• Número medio de personal técnico que interviene en un problema.
• Número de soluciones provisionales actualmente activas (workarounds).
• Mejora de la disponibilidad de los servicios generada por la resolución de
problemas.
• Productividad inducida en el negocio por una mayor estabilidad de los servi-
cios. Está métrica puede ser bastante subjetiva.
Los resultados esperados por una buena gestión del problema se pueden apreciar a
través de:
• La reducción de la cantidad de incidentes, al eliminar la causa raíz que los
provoca y, por tanto, evitar su recurrencia.
• La reducción de tiempo para la reparación de un incidente (MTTR), debido
a la base de conocimiento que se va generando, junto con un incremento de
la tasa de resolución de incidentes en primer nivel.
• La reducción de los tiempos necesarios para la resolución de los problemas.
• La disminución de los costes asociados a la resolución.
En el gráfico de la figura 8.3.9 se muestra el resumen de los indicadores más relevan-

tes para este proceso seleccionados por un grupo de trabajo de itSMF España. En él
se aprecia que la gestión del problema es un proceso interno de TI, con poca visibili-
dad directa por parte del negocio. Por ello, no tiene presente ningún KGI de TI.
de itSMF España

Si bien, en el ámbito del proceso, las fronteras entre incidentes y problemas están
claramente delimitadas, en el ámbito de los técnicos especialistas puede ocurrir que
tengan que intervenir primero para restaurar el servicio y posteriormente para eli-
minar la causa raíz, participando así en los dos procesos asumiendo diferentes roles.
Esta situación puede implicar un conflicto de intereses entre la dedicación a la res-
tauración del servicio y la dedicación a la eliminación de los defectos. Se debe dife-
renciar claramente entre la actuación del personal técnico bajo la resolución de pro-
blemas y en caso de incidentes.
Los participantes en este proceso deben tener una cualificación técnica muy alta,
involucrando a los especialistas, internos o externos, que se necesiten.
Como en el resto de los procesos, los roles que intervienen en el proceso se estruc-
turan en los roles propios del proceso y los roles ajenos al proceso (el gestor del
nivel de servicio).
Los roles propios del proceso son los siguientes:
• El gestor de problemas (gestor del proceso o process manager). Es el respon-
sable de la operación diaria del proceso de gestión de problemas, velando
por la implicación de los equipos ante la definición de un problema, asegu-
rando que se cumplen los SLA, y coordinando los escalados entre grupos en
caso de necesidad.
• Líder de equipo de gestión del problema. Es el responsable de liderar de
forma eficaz y eficiente al equipo de trabajo encargado de la resolución
de un problema
• Analista técnico de problemas. Es el rol encargado de llevar a cabo la investi-
gación, diagnóstico y resolución de problemas. En este rol participan los téc-
nicos especialistas de todo tipo, de desarrollo, técnico de sistemas, del hard-
ware, etc., que participan en las actividades de investigación y diagnóstico
del problema y en la resolución de errores.
• El responsable del centro de servicio al usuario, por la estrecha relación entre
el soporte en la primera línea de incidentes y la gestión del problema.
• El responsable de desarrollo y el responsable de infraestructuras o de tecno-
logía, pues deben proveer técnicos especialistas en las disciplinas que se nece-
siten para identificar y resolver los problemas.
Los roles de mayor relevancia que participan en el proceso de gestión del problema
se representan en el gráfico de la figura 8.3.10.
Roles del proceso
Responsable de la
SGSTI
Administrador y
Gestor de soporte del proceso
problemas
Propietario del
modelo (SGSTI)
Líder de equipo Analista técnico

de gestión del problema de problemas
Gestor del
service desk
Figura 8.3.10. Roles principales del proceso de gestión del problema.
Resumen
La misión del proceso de gestión del problema es evitar que se produzcan inciden-
tes repetitivos o nuevos. Este proceso es uno de los más eficaces y que mejores
resultados proporciona, pues va buscando y subsanando defectos en los servicios
para hacerlos más estables.
Es un proceso de fácil implementación ya que no requiere grandes herramientas, ni

la involucración de todo el personal. Con dos expertos el proceso empieza a dar sus
resultados. La gestión del problema se divide principalmente en dos grandes blo-
ques: la gestión reactiva (que comprende el control de problemas y el control de
errores) y la gestión proactiva (que busca problemas latentes).
Para conseguir obtener toda la eficiencia del proceso, en sus aspectos reactivos y
proactivos, se debe disponer de un proceso de gestión del incidente suficientemente
maduro que registre información suficiente para realizar los análisis forenses. El
principal resultado de este proceso es la estabilidad de los servicios, con la visibili-
dad ante el negocio que esto tiene.
La reducción de los incidentes produce un efecto positivo en el estrés y carga de
trabajo de los equipos de soporte.
Además, este proceso es un generador de conocimiento en forma de errores cono-
cidos (que contienen la descripción del problema, la causa raíz y su solución).
La gestión del problema no se limita a una mera enumeración de los errores, sino
que trabaja en todo el ciclo de vida de la solución, y a lo largo de todo el ciclo de
vida del servicio
Beneficios
Entre las ventajas de adoptar un enfoque formal de gestión del problema se inclu-
yen las siguientes:
• Mejora de la calidad de los servicios de TI. La gestión del problema ayuda a
generar un ciclo en el que la calidad de los servicios de TI se incrementa rápi-
damente.
• Reducción del volumen de incidentes. La gestión del problema contribuye a
reducir el número de incidentes que interrumpen el curso normal del negocio.
• Aporte de soluciones permanentes. Se produce una reducción gradual del
número e impacto de problemas y errores, ya que las soluciones son perma-
nentes y no parches provisionales.
• Incremento del conocimiento de la organización. El proceso de gestión del
problema genera la base de errores conocidos que permite reutilizar las expe-
riencias previas.
• Mejora del ratio de resoluciones en la primera línea de soporte. El conoci-
miento generado sobre la resolución de errores permite resolver mayor
número de incidentes en la primera línea.
Describa un problema relevante que haya ocurrido en su organización, y
sobre él:
• Realice un esquema Ishikawa (raspa de pez) con los errores más fre-
cuentes para un servicio crítico, agrupados según esta metodología de
análisis de causa-raíz.
• En el caso, describa qué se hizo mal, qué se hizo bien y que cambia-
ría en su organización.
9 Capítulo 9
Procesos
de control
CMDB 9.1. Gestión de la configuración
9.2. Gestión del cambio


9. Procesos de control 621
Tener todo bajo control es el primer deseo de los responsables de TI. Los siste-
mas de información, cada vez más importantes para la empresa, deben evolucio-
nar de una forma controlada. La industria ha consensuado dos procesos cuyo
énfasis se centra en este deseado control de TI y de sus servicios: el proceso de la
gestión de la configuración y el proceso de la gestión del cambio. El primero con-
trola la información sobre los elementos considerados clave para la gestión de los
servicios de TI, y el segundo, que no se cambie nada sin seguir las reglas preesta-
blecidas.
Se puede considerar que la gestión de la configuración supone para TI lo que la
imprenta para la Humanidad: una forma industrializada de tratamiento con rigor
del conocimiento común. Efectivamente, los servicios de TI cada vez más críti-
cos no se pueden gestionar mediante acciones voluntaristas de algunos profesio-
nales de TI, la información y el conocimiento de TI debe ser tratado con rigor
bajo una estricta política definida en la empresa. Sólo de esta forma se podrá
garantizar que las decisiones se toman con la información precisa y fidedigna.
Al avanzar en el presente capítulo se apreciará cómo el proceso de gestión de la
configuración articula las políticas y mecanismos que hacen posible que la informa-
ción que se necesite para la gestión de TI esté disponible y con la calidad y fiabili-
dad deseadas.
Por otra parte, el mayor porcentaje de incidentes y fallos en los servicios de TI pro-
vienen de errores o defectos introducidos al cambiar. Pero los cambios son necesa-
rios para mantener los servicios alineados con la evolución del negocio y de la tec-
nología.
El proceso de la gestión del cambio introduce una serie de mejores prácticas que
ayudan a que la necesaria actividad de realizar modificaciones se realice de la forma
más segura y controlada posible.
Las prácticas más importantes que se aprenderán es este capítulo son las siguientes:
• Cómo diseñar y gestionar la base de datos de la gestión de la configuración.
• Cómo articular la información común para que sea útil.
• Los dos roles para garantizar el control: el gestor de la configuración y el
gestor del cambio.
• Cómo pone orden un simple formulario, la petición de cambio.
• A definir y articular el comité de control de cambios, que posibilita la
coordinación de todos los recursos humanos que están involucrados en un
cambio.
• La necesidad de disponer de una la lista con la planificación y control de

todos los cambios previstos.
• La importancia de revisar y confirmar la idoneidad de un cambio después de
su implantación.
CMDB
9.1. Gestión de la configuración 623
9.1. Gestión de la configuración
Figura 9.1.1. Actividades principales del proceso de gestión de la configuración
Una organización sin información está completamente “ciega” y es totalmente

dependiente del conocimiento traspasado verbalmente entre las personas que for-
man TI. Las decisiones se toman únicamente con la información que los profesio-
nales de TI retienen en su cabeza.
Según va creciendo la organización o va rotando el personal, ese conocimiento y
dominio que los primeros tenían se va haciendo cada vez más difícil de mantener
y empiezan a aparecer los “apaños”, listas o anotaciones que unos y otros hacen por
doquier. Hasta que llega un momento en el que ya no es posible la gestión bajo esta
forma artesanal y rudimentaria de manejar la información y se hace necesario que
el conocimiento se almacene y retenga con rigor.
En una organización sin gestión de la configuración es frecuente encontrarse situa-
ciones como:
“– ¿Me puedes decir qué infraestructura soporta el servicio de venta online? y ¿cuáles
son los niveles de servicio que debemos cumplir?
– Espera, te lo digo mañana, pues tengo que cruzar varias listas y preguntar a los téc-
nicos de servidores, de red, de aplicaciones, etc.”
“– ¿Sabes qué técnico está de guardia este fin de semana?

– No sé, cada semana cambia, llama a Pedro y él te dirá a quiénes les toca el próximo.”
“– Tengo en línea a un cliente de TI y me pide que le actualicemos el listado de las
empresas de fabricación de componentes metálicos de aluminio en la región para un
mailing; esto es un poco raro ¿qué le digo?
– Yo creo que esta actividad no la hacemos nosotros, es el propio departamento de mar-
keting el que lo hace, llámales y pásales el marrón.”
“– Voy a instalar un parche del sistema operativo en 5 servidores, ¿crees que afectará a
alguna aplicación?
– Desde la consolidación y virtualización no hay quien se aclare, para estar seguros
convoca una reunión con todos los técnicos de sistemas para que cada uno diga si le
impacta o no.”
Como se aprecia en la última situación, las organizaciones están consolidando sus

infraestructuras y virtualizando las instancias de los sistemas operativos, el almace-
namiento, etc. En este escenario, la infraestructura se comparte, y la facilidad de
asignación de recursos hace más difícil conocer de memoria a qué está dedicado
cada equipo, pues la misma infraestructura física soporta muchos servicios (véase la
figura 9.1.1).
La gestión de la configuración es el proceso que se ocupa de controlar y proveer
la información común sobre TI y sus servicios que necesitan todos los procesos o
áreas de TI. Este proceso vuelca en un repositorio la información importante a
compartir por cualquier área de TI. Se centra principalmente en información
esencial o que necesita ser compartida entre las diversas áreas. Este repositorio es
una base de datos lógica que puede estar formada por múltiples bases de datos
y formas de almacenamiento, y repartida en múltiples emplazamientos. En la
figura 9.1.2 se presenta un esquema introductorio al proceso.
Es un proceso interno a TI, no visible directamente para los usuarios y clientes.
Está centrado en facilitar información precisa y fiable al resto de la organización de
TI. Por tanto, su labor es la de bibliotecario o clasificador, similar a otras discipli-
nas como la gestión de inventarios y la gestión de activos, pero con un foco claro
en la gestión de la información de configuración que se ha definido como necesaria
para ser compartida.
El que sea un proceso interno de TI no le merma importancia. De hecho es uno de
los procesos esenciales, que facilitando información precisa, hace posible el éxito
de la actividad de TI.
CMDB

configuración • Información precisa y actualizada
sobre los componentes de TI.
Definición: • Visión de todos los elementos que

componen un servicio y las relaciones
Proceso responsable de gestionar entre ellos.
y mantener actualizada toda la
• Fiabilidad en las actuaciones al
información común que necesitan
disponer de información precisa.
las áreas de TI.
• Eficiencia en el trabajo al tener
accesible la información común que se
Objetivo: necesita.
Definir y controlar los componentes • Compartir la información común entre
del servicio y de la infraestructura, todos los procesos.
y mantener información precisa
• Control de todos los elementos
sobre la configuración.
software instalados.
Figura 9.1.2. Introducción al proceso de gestión de la configuración
El proceso, primero define qué tipo de información es esencial compartir (alcance

y profundidad), establece las políticas para su gestión, diseña el soporte informá-
tico para la misma, identifica los elementos que se van a cargar, para pasar a con-
trolar sus actualizaciones posteriores. Además, realiza verificaciones y auditorías
para garantizar la fidelidad de la información compartida.
Por tanto, la gestión de la configuración garantiza que está correctamente regis-
trada la información necesaria para la gestión de los servicios. La misión del pro-
ceso de gestión de la configuración es proporcionar información veraz de los com-
ponentes de TI y sus relaciones al resto de los procesos.
Los principales aportes que realiza la gestión de la configuración al proveedor de
TI pueden resumirse en:
• Llevar el control de todos los elementos de configuración de la infraestruc-
tura de TI con el adecuado nivel de detalle y gestionar dicha información a
través de la base de datos de configuración (CMDB).
• Proporcionar información precisa sobre la configuración de TI a todos los
diferentes procesos de gestión.
• Interactuar con la gestión del incidente, del problema, del cambio y de la
entrega de manera que éstas puedan resolver más eficientemente las incidencias,
encontrar rápidamente la causa de los problemas, realizar los cambios

necesarios para su resolución y mantener actualizada en todo momento la
CMDB.
• Monitorizar periódicamente la configuración de los sistemas en el entorno
de producción y contrastarla con la almacenada en la CMDB para subsanar
discrepancias.
• Este proceso también gestiona el repositorio que almacena las diversas entre-
gas de software, denominado biblioteca de software definitivo (DSL, Defini-
tive Software Library). En ITIL v2 es diferente, ya que esta responsabilidad
recae sobre el proceso de gestión de la entrega.
Los tres pilares en los que se sustenta este proceso se resumen en el esquema de la
figura 9.1.3.
Figura 9.1.3. Bases de la gestión de la configuración
La gestión de la configuración se articula en torno a dos conceptos principales: los

elementos de configuración, denominación dada a todo componente de TI cuya
información es necesaria para la gestión de los servicios de TI; y la base de datos de
la configuración, repositorio informático en el que se almacenan los elementos de
configuración. En el esquema de la figura 9.1.4 se presentan la CMDB junto a los
componentes más destacados de este proceso.
CMDB
Servicios
Documentación
SLAs
CI CI CI CI
Gestor de la CI CI
configuración CI CMDB
CI HW
CI CI CI CI CI
SW
Base de datos de gestión
de la configuración Elementos de configuración
(CMDB) (CI)
El resto de los procesos

utilizan la información Línea base
5. Planificación e implementación de nuevos servicios o de servicios modificados (baseline)
DSL 6. Procesos de la provisión del servicio
Biblioteca de continuidad y
disponibilidad
6.2 Generación de
informes del servicio
6.4 Elaboración de
presupuesto y contabilidad
software definitivo
Figura 9.1.4. La gestión de la configuración y la CMDB son considerados

el núcleo de la gestión de los servicios de TI
Los componentes principales que se emplean en el proceso de gestión de la confi-

guración son los siguientes:
Base de datos de la gestión de la configuración (CMDB, Configuration Mana-
gement Data Base). Es el repositorio que alberga los registros sobre los elementos
de configuración que se hayan decidido incluir. Contiene los detalles relevantes de
cada elemento de configuración o CI (atributos e historial), así como detalles
de las relaciones importantes entre ellos.
Esta base de datos debe incluir únicamente la información común a los procesos
que se haya planificado compartir. No hay que confundirla con la información o
base de datos que cada proceso y cada área de TI deben disponer y controlar, que
retendrán la información que se necesite para cada actividad. De esta forma, la
gestión del incidente dispondrá de una base de datos de los incidentes ocurridos
con las indicaciones para resolverlos, de igual manera que ocurre con el resto de
los procesos. De toda esta información gestionada por los procesos y áreas, sólo se
alojará en la CMDB la que se haya decidido que compartirla aporta valor. No obs-
tante, es necesaria una buena integración entre las herramientas, de tal forma que
desde la CMDB se pueda consultar los registros asociados a un CI que existan en las
herramientas de soporte específico de otros procesos (incidente, capacidad, etc.).
La CMDB está formada por:
• Fichas con la información detallada de cada elemento de configuración, pero
no suele albergar el elemento de configuración en sí mismo. Sólo en los
casos en que los elementos de configuración son documentos electrónicos
(SLA, contratos, etc.), se podrán incluir el CI de forma completa en la CMDB.
Los archivos fuentes y los ejecutables de los programas no se suelen incluir
en la CMDB.
• Relaciones entre los diferentes elementos de configuración.
Biblioteca de software definitivo (DSL, Definive Software Library). Es un repo-

sitorio, archivo físico o electrónico, que aloja todos los archivos fuentes y ejecuta-
bles de los productos y programas que utilizan los servicios. La DSL contiene los
archivos completos correspondientes a todo CI de software, con un histórico de sus
versiones. Toda versión del CI recogida en la CMDB debe tener sus ficheros origi-
nales en la DSL, para poder reinstalar el CI software cuando sea necesario.
Hay que destacar que en ITIL v2 la gestión de la DSL se encarga al proceso de
gestión de la entrega. En ISO/IEC 20000, el control de la DSL lo ejercita el pro-
ceso de gestión de la configuración; situación que parece más razonable y acorde
con las funciones requeridas de “bibliotecario”. En ITIL v3, la DSL se denomina
DML (biblioteca de medios definitivos) y está gestionada por el proceso de ges-
tión de la configuración y activos del servicio.
En cualquier caso, la actualización de la DSL con las últimas versiones del software
instalado parece razonable que lo realice la gestión de la entrega, con la supervisión
de la gestión de la configuración.
Por tanto, la CMDB contiene las fichas que identifican y catalogan los elementos
software, mientras que la DSL contiene los archivos que contienen el software y sus
versiones.
Luego, tanto en la planificación de la gestión de la configuración como en sus activi-
dades posteriores habrá que considerar el diseño, implementación y control de la DSL.
Elemento de configuración (CI, Configuration Item). Un CI es todo compo-
nente físico o lógico de tecnología de la información necesario para la prestación
del servicio. Como ejemplo se citan los siguientes:
CMDB
• Dispositivos hardware, como por ejemplo, servidores, almacenamiento

externo, PC, impresoras, equipos de comunicaciones, etc.
• Software: sistemas operativos, productos software, todo tipo de aplicaciones,
scripts, parametrizaciones de productos, etc.
• Documentación: manuales, acuerdos de niveles de servicio, contratos de
soporte, etc.
• Personas que intervienen en la prestación del servicio.
• Localizaciones, edificios, oficinas, etc.
• Servicios que presta TI.
• Entidades lógicas, como particiones, clusters, instancias, etc.
• Indicadores, métricas, informes, etc.
En resumen, CI es todo componente que ha de ser gestionado por la organización

de TI y cuya ficha vaya a estar bajo el control de la gestión de la configuración y
que, por tanto, estará sujeto a un control de cambios formal.
Hay que determinar cuál es el nivel más detallado de información que interese con-
trolar en el proceso. Por ejemplo, se tratará como elemento de configuración un
PC, pero no compensa tratar como elementos independientes el ratón, la memoria,
o el disco interno, que en todo caso serán características del PC.
Los elementos de configuración pueden ser muy diferentes en complejidad,
tamaño y tipo, desde un sistema o servicio completo (incluyendo todo el hardware,
software y documentación, etc.), hasta un único módulo o un simple componente
hardware. Cada organización deberá determinar el alcance y profundidad de la
ficha de información sobre cada tipo de elemento.
Un CI debe tener asociados o referenciados los incidentes, problemas, cambios,
etc., en los que está o ha estado involucrado.
Línea base de configuración (baseline). Es la configuración (versiones) de los ele-
mentos de configuración que forman un servicio o sistema en un momento deter-
minado del tiempo. Es una “foto” tomada en un instante determinado sobre el
estado y versiones de todos los CI que componen un servicio. Recoge tanto la
estructura como todos los detalles necesarios para que el servicio o sistema pueda
reimplantarse o restaurarse posteriormente, en caso de necesidad.
Por ello, una línea base se utiliza como medida de seguridad antes de realizar un
cambio importante y facilita información para regresar a la situación inicial. Tam-
bién puede ser establecida para el paso a producción de nuevos CI y para facilitar
información en una situación de recuperación ante desastres.
La línea base recoge información de la CMDB sobre el estado en un instante deter-

minado de la configuración de un CI o de un conjunto de CI, es decir, las fichas de
los CI. Como la línea base contiene sólo la información del estado de los CI, para
la recuperación completa se necesitarán también las copias de seguridad realizadas,
los archivos fuentes y ejecutables, la parametrización realizada, etc. (contenidas en
la DSL).
Relaciones entre los elementos de configuración. Un CI no está aislado. Nece-
sita e interactúa con otros elementos para componer el servicio final que presta TI.
Por ello, es importante definir, cargar y controlar en la CMDB las relaciones entre
los elementos de configuración. Las relaciones aportan un valor excepcional a la
información sobre la configuración.
Las relaciones entre dos CI pueden ser de diversos tipos. A continuación se mues-
tran ejemplos de ellas:
• Usa. Un CI del tipo empleado utiliza al otro CI del tipo PC.
• Parte de (hijo). Un componente de red es parte de una red.
• Formado por (padre). Una red está formada por componentes de comuni-
caciones.
• Conectado a. Un CI de almacenamiento está conectado a un CI servidor.
• Instalado en. Un CI software está instalado en un CI servidor.
• Localizado en. Un CI está ubicado en otro CI del tipo localización.
Las relaciones nos permiten obtener todos los CI que participan en un servicio
determinado.
Con las relaciones se construyen estructuras de configuración o esquemas de rela-
ción, que tienen por eje central el CI que interese conocer en un momento deter-
minado. Forman, por tanto, el árbol en el que se estructuran las categorías de los
elementos de configuración. Así, los esquemas de relación más habituales son
los siguientes:
• Esquema de relación de un servicio, que muestra todos los componentes que
participan en ese servicio.
• Esquema de relación de un servidor, para conocer todo lo instalado en él y
en que servicios está soportando.
• Esquema de relación de red, muestra los componentes de una red.
CMDB

Las entradas del proceso proporcionan la información necesaria para actualizar la
CMDB, que proviene de los resultados de las herramientas de autodescubrimiento
de infraestructura (muy habituales para los PC y los elementos de red), de cargas de
datos realizadas por lotes (provenientes de actualizaciones o de un esfuerzo manual
para ampliar el alcance o la profundidad de la CMDB), o de otros procesos (princi-
palmente de gestión del cambio, gestión de la entrega y gestión de nivel de servicio).
Las Normas ISO/IEC 20000 siguen una definición de actividades para este pro-
ceso muy similar a la establecida en ITIL v2, pero por desgracia, ambas denomina-
ciones resultan poco afortunadas y algo confusas, pues bajo la actividad denomi-
nada identificación se centra principalmente en la localización y etiquetado de CI.
Bajo la actividad denominada control se realiza la carga y actualización de informa-
ción (CMDB y DSL), y en el seguimiento del estado se informa respondiendo a
las consultas del resto de la organización.
Las funcionalidades que debe desarrollar la gestión de la configuración se resumen
sucintamente en la figura 9.1.5.
Desencadenantes 3 Planificación e implementación de Salida principal:

del proceso: la gestión de la configuración. Ü Plan de gestión de la
Ü Detalles para 3 Identificación de configuración configuración.
actualizar la CMDB. (estructurar). Ü CMDB creada, cargada
Ü Resultados 3 Control de configuración y actualizada.
herramientas (registrar y actualizar). Ü DSL creada, cargada y
autodescubrimiento. 3 Seguimiento del estado de actualizada.
Ü Cargas de datos. la configuración e informes ÜInformación de detalles
Ü Cambios. (informar). del estado de la
3 Verificación y auditoría configuración (CI).
Ü Ficheros para actualizar
de la configuración.
la DSL. Salidas secundarias:
3 Supervisión y mejora del
Ü Fuentes y ejecutables Ü Inconsistencias.
proceso.
de programa. Ü Información del proceso.
Ü Software del Ü Plan de mejora del
fabricante. Tanto de la CMDB como de la DSL. proceso.

Para cumplir su finalidad, la gestión de la configuración articula su trabajo en torno

a las siguientes actividades:
• Planificación e implementación del proceso de gestión de la configuración,
incluyendo el diseño e implementación de la CMDB y de la DSL en sus res-
pectivas herramientas.
• Identificación de la configuración (estructurar), que permite establecer la
estructura de configuración (alcance y detalle de la información sujeta a ges-
tión de la configuración y recogida en la CMDB) y políticas de nomencla-
tura para la numeración, clasificación y etiquetado de los elementos de con-
figuración (CI).
• Control de la configuración (registrar y actualizar), para que los cambios en
los elementos de configuración se actualicen en la CMDB y DSL según los
mecanismos definidos. Esta actividad realiza la carga las fichas de los CI en la
CMDB; controla la carga del software (archivos) en la DSL, que realiza gestión
de la entrega a la aceptación de cada entrega; y asegura que sólo se registran
elementos autorizados e identificables, desde su recepción hasta su retirada. Se
debe asegurar que no se añada, modifique, reemplace o elimine ningún CI sin
la documentación de control adecuada. Éstas actuaciones sólo se realizarán por
el personal autorizado a través de una correcta asignación de roles.
• Seguimiento del estado de la configuración e informes (informar). Propor-
cionar información exacta sobre las la configuración y su documentación
para apoyar a todos los demás procesos de gestión del servicio. Así, se facili-
tan datos consistentes para la gestión del incidente, gestión del problema,
gestión del cambio y gestión de la entrega.
• Verificación y auditoría de la configuración. Comprueba los registros de con-
figuración, contrastándolos con la infraestructura real, y corrige cualquier
excepción. Realiza la auditoría formal de la información contenida.
• Supervisión y mejora del proceso, aportando entradas al plan de mejora
general de la gestión del servicio.
En la figura 9.1.6 se presenta un esquema de estas actividades que forman la ges-

tión de la configuración.
Las principales salidas del proceso son las siguientes.
• Plan de gestión de la configuración. Documento resultante de la planifica-
ción de la implantación de la configuración.
• CMDB creada, cargada y actualizada. La base de datos de gestión de la con-
figuración se crea y se carga con la configuración inicial, de acuerdo al
CMDB
Identificación de
la configuración Control de configuración
(estructura, alcance y detalle)
(registrar y actualizar)
Modificaciones
a los CI
Planificación e implementación
de la gestión de la
configuración Otros procesos

CI CI CI CI disponibilidad
del servicio
informes del servicio
presupuesto y contabilidad
CI CI de entrega
8. Procesos
de relaciones
CMDB
10.1 Proceso de gestión 7.2 Gestión de las
CI CI
Verificación y CI CI CI CI CI
auditoría de la
configuración
DSL
PDCA Supervisión y Seguimiento del estado de
SGSTI mejora del proceso la configuración e informes
(informar)
Fuente: HP y e.p.
Figura 9.1.6. Actividades principales de gestión de la configuración
alcance y nivel de detalle establecidos. Se actualiza con los cambios produci-

dos sobre los elementos de configuración.
• DSL creada, cargada (inicial) y actualizada (a través de gestión de la
entrega).
• Información detalles del estado de la configuración. Información sobre
el estado y detalles de la configuración almacenados en la CMDB y DSL
que es requerida por otros procesos o áreas de la organización de TI para el
desarrollo de su actividad.

La planificación e implementación de este proceso se debe realizar de la misma forma
que el resto de procesos, bajo el amparo y liderazgo del proceso de planificación e
implementación de la gestión del servicio (véase el capítulo 4). El equipo de imple-

mentación de la gestión del servicio también asumirá la implementación de este pro-
ceso, teniendo en cuenta lo que dictan estas normas y las características propias de la
En el apartado 9.1 de estas normas se establecen los requerimientos y recomenda-
ciones que se deben cumplir en la planificación e implementación de la gestión de
la configuración. Así, se establece que la planificación del proceso debe definir el
propósito, objetivos, alcance, estrategia, políticas y procedimientos, así como,
la organización e infraestructura tecnológica necesaria para la implantación del
proceso.
La implantación de este proceso es ardua y muchas veces desemboca en el fracaso,
principalmente porque se suele ser muy ambicioso en los objetivos iniciales de
información a albergar en la CMDB y después de un tremendo esfuerzo en la carga
inicial, no es fácil mantener los datos actualizados. Por ello, se suele recomendar
que se inicie con unos objetivos muy acotados; empezar poco a poco, con una
estructura liviana de CMDB para ir creciendo según vaya madurando la implanta-
ción de la monitorización y el descubrimiento automático de la infraestructura, que
permitirá actualizar automáticamente los cambios en los elementos de configura-
ción (CI).
ISO/IEC 20000-1 pone más énfasis en el control de los activos, requiriendo un
vínculo claro con la contabilidad financiera, el control de los activos de software (en la
DSL) y sentando las bases de la CMDB.
UNE-ISO/IEC 20000-1
Debe existir una visión integrada para la planificación de la gestión del cambio y de
la configuración.
El proveedor del servicio debe definir la interfaz con los procesos de contabilidad
financiera de activos.
Nota: La contabilidad financiera de los activos queda fuera del ámbito de esta sección.
Debe existir una política que defina qué se considera como elemento de configura-
ción y qué componentes lo constituyen.
Deben estar controladas, en una biblioteca física o electrónica segura, las copias
maestras de los elementos de configuración digitales, con referencias a los registros
de configuración, por ejemplo software, productos de prueba, documentos de
soporte.
Todos los elementos de configuración deben ser identificables de manera única y
registrados en la base de datos de gestión de la configuración, cuyo acceso para
CMDB
actualizaciones se debe controlar de manera estricta. La base de datos de gestión

de la configuración se debe gestionar y verificar activamente para asegurar su fiabi-
lidad y precisión. El estado de los elementos de configuración, sus versiones, ubica-
ción, cambios y problemas relacionados, así como la documentación asociada
deben estar visibles para quienes lo requieran.
En cambio, ISO/IEC 20000-2 se centra más en las recomendaciones prácticas para

que el proceso sea efectivo.
UNE-ISO/IEC 20000-2
La gestión de la configuración se debe- Este gestor responsable debería dispo-

ría planificar e implementar junto con la ner de la información necesaria para
gestión del cambio y la gestión de delegar esta responsabilidad, por ejem-
entregas para asegurar que el provee- plo, la persona que autoriza un cambio
dor del servicio pueda gestionar sus podría requerirle información del coste,
activos y configuraciones de TI de forma riesgos, impacto del cambio y recursos
efectiva. para la implementación.
Debería estar disponible una informa- La infraestructura y/o los servicios debe-
ción precisa sobre la configuración para rían tener un plan(es) actualizado(s) de
dar soporte a la planificación y al control gestión de la configuración, que puede
de los cambios a medida que los siste- ser independiente o formar parte de
mas y los servicios nuevos y modificados otros documentos de la planificación.
son liberados y distribuidos. El resultado Éstos deberían incluir o describir:
debería ser un sistema eficiente que inte- a) ámbito, objetivos, políticas, roles y
gre los procesos de gestión de la infor- responsabilidades normalizados;
mación de configuración del proveedor
del servicio con los de los clientes y b) los procesos de gestión de la con-
suministradores, cuando proceda. figuración para definir los elemen-
tos de configuración de los servi-
Todos los activos y configuraciones prin- cios e infraestructuras, controlar
cipales se deberían tener en cuenta y los cambios en las configuracio-
tener un gestor responsable que ase- nes, registrar e informar del estado
gure que se mantienen la protección y de los ítems de configuración y
el control apropiados, por ejemplo: los verificar la integridad y la exactitud
cambios son autorizados antes de la de los elementos de configuración;
implementación.
c) los requisitos para la contabili-
Se podría delegar la tarea de imple- dad, el seguimiento y la auditoria,
mentar los controles, pero la responsa- por ejemplo, para propósitos de
bilidad sigue estando en el gestor res- seguridad, legales, regulatorios o
ponsable. de negocio;
d) el control de la configuración (ac- tener los activos y las configura-

ceso, protección, versionado, cons- ciones bajo control y mantener el
trucción, control de entrega); sistema de gestión de la configu-
e) el proceso de control de los ele- ración, por ejemplo, formación;
mentos de contacto que identifi- g) la gestión de los suministradores y
quen, registren y gestionen los subcontratistas que estén llevando
elementos y la información de la a cabo labores de gestión de la
configuración en los límites comu- configuración.
nes a dos o más organizaciones,
por ejemplo: interfaces de siste- Nota: Se debería implantar un nivel apropiado
mas, versiones; de automatización para asegurar que los
procesos no se conviertan en ineficaces,
f) la planificación y el estableci- o en proclives al error o que no pudieran
miento de los recursos para man- ejecutarse.
Además de lo indicado en la segunda parte de estas normas, es conveniente consi-

derar los siguientes aspectos:
• Designar un responsable: una descentralización excesiva puede generar
descoordinación y llevar al fracaso todo el proceso.
• Invertir en una herramienta de software adecuada para la CMDB y DSL.
En grandes organizaciones es esencial y suele ser uno de los primeros pro-
yectos que se inician en la gestión del servicio, ya que una solución ama-
nuense es impracticable. Aunque en el caso de pequeñas instalaciones y,
sobre todo si el volumen de CI que se van a gestionar es pequeño, podría
considerarse el uso de una simple herramienta ofimática.
• Realizar un cuidadoso análisis de los recursos ya existentes: gestión de
activos, autodescubrimiento, etc.
• Establecer claramente un alcance y objetivos modestos inicialmente, defi-
niendo el nivel de detalle adecuado en los CI. Una falta de planificación, así
como un alcance y grado de detalle demasiado ambicioso en una fase tem-
prana de la implementación del proceso, conducirá con total certeza a una
gestión de la configuración con información desactualizada, con las graves
consecuencias que esto supondrá para el resto de los procesos.
• Coordinar las actualizaciones estrechamente con la gestión del cambio, la
gestión de la entrega y los departamentos de compras o suministros.
Uno de los aspectos importantes a la hora de garantizar el éxito de la actividad de pla-

nificación es la determinación de los procedimientos, las estructuras organizativas y el
contexto técnico para la generación y mantenimiento de la CMDB. La importancia
es mayor si se tiene en cuenta que muchas veces se piensa que para alimentar una base
CMDB
de datos de configuración basta con disponer de un formulario de entrada de datos y

disponer de suficientes recursos (horas/hombre) introduciendo los datos para cada
cambio o manipulación que se realice en la infraestructura de TI. La carga y actuali-
zación manual es una tarea laboriosa y rudimentaria. Aunque para algunos elementos
no habrá otra forma de proceder, se debe intentar disponer de ayudas al poblado de
datos (autodescubrimiento) para que, ante cambios organizativos o tecnológicos, se
facilite el trabajo al técnico y se garantice la consistencia y fiabilidad de la información
de la CMDB.
La automatización utiliza sistemas avanzados de asignación de activos basados en
reglas de decisión que facilitan la laboriosa tarea de asignación de propietarios, cla-
sificadores, etc., que son el “pan de cada día” de la gestión de la configuración.
El plan de gestión de la configuración debe contener al menos la información indi-
cada en la figura 9.1.7.
Plan de gestión de la configuración
• Propósito.
• Objetivo.
• Alcance.
• Políticas y procedimientos.
• Estrategia de implantación.
• Planificación de actividades:
– Diseño de la CMDB.
– Diseño de la DSL.
• Organización.
• Herramientas de soporte.
• Análisis de la información disponible y sus
fuentes.
Figura 9.1.7. Índice ejemplo del plan de gestión de la configuración
Las principales dificultades con las que se encuentra la implementación de la ges-

tión de la configuración son las siguientes:
• Un diseño teórico no realista: no involucrar a los equipos adecuados a la
hora de definir los campos y de registrar el contenido de la CMDB, puede
llevar a tener una CMDB inútil.
• Una incorrecta planificación: es esencial programar correctamente las activi-

dades necesarias en la identificación de la configuración para evitar duplica-
ciones o incorrecciones.
• Una estructura muy pesada de la CMDB: mantener actualizada una base de
datos de la configuración excesivamente detallada y compleja puede ser una
tarea muy engorrosa y que consuma demasiados recursos.
• Herramientas inadecuadas: es necesario disponer del software adecuado para
agilizar los procesos de registro y sacar el máximo provecho de la CMDB y
la DSL.
• Falta de coordinación con la gestión de cambios y de la entrega que imposi-
bilita el mantenimiento actualizado de la CMDB y la DSL.
• Falta de organización: es importante que haya una correcta asignación de
recursos y responsabilidades. Es preferible que la gestión de la configuración
se lleve a cabo por personal independiente y especializado.
• Falta de compromiso: los beneficios de la gestión de la configuración no son
inmediatos y son casi siempre indirectos, lo que puede provocar el desinterés
de la dirección de la empresa y consecuentemente de los implicados.
Identificación de la configuración (estructura, alcance y

detalle)
La identificación de la configuración es la actividad dedicada a localizar, identificar
y clasificar los elementos de configuración existentes, para su carga posterior (por la
actividad de control) en la CMDB y la DSL. Así, los CI deberán desglosarse e iden-
tificarse unívocamente para permitir el control y registro al nivel que se necesite
por los procesos o unidades usuarias de la CMDB.
UNE-ISO/IEC 20000-1
Se debe definir la información que se debe registrar para cada elemento, y se

deben incluir las relaciones y la documentación necesaria para la gestión efectiva
del servicio.
La gestión de la configuración debe proporcionar los mecanismos para identificar,
controlar y hacer el seguimiento de las versiones de los componentes identificables
del servicio y de la infraestructura. Se debe asegurar que el grado de control es sufi-
ciente para cubrir las necesidades del negocio, los riesgos de fallo y la criticidad del
servicio.
CMDB
UNE-ISO/IEC 20000-2
Todos los elementos de configuración g) activos físicos que sean necesarios

deberían estar identificados de manera para la gestión financiera de acti-
unívoca y estar definidos por atributos vos o bien por motivos de nego-
que describan sus características funcio- cio, por ejemplo: medios magné-
nales y físicas. La información debería ticos seguros, equipamiento;
ser relevante y auditable. h) documentación relativa al servi-
En la base de datos de la configuración cio, por ejemplo: SLAs, procedi-
se deberían utilizar y registrar los marca- mientos;
dos apropiados u otros métodos de i) instalaciones para el soporte del
identificación. servicio, por ejemplo: energía eléc-
trica para la sala de ordenadores;
Los elementos a ser gestionados se debe-
rían identificar usando los criterios de j) relaciones y dependencias entre
selección establecidos y deberían incluir: los elementos de la configuración.
a) todas las distribuciones y entregas Nota: Otros elementos que podrían se considera-
de los sistemas de información y del dos como elementos de configuración son:
software (incluyendo software de a) otra documentación;
terceras partes) y la documentación b) otros activos;
relativa de los sistemas, por ejem- c) otras instalaciones, por ejemplo: empla-
plo, las especificaciones de requisi- zamientos;
tos, diseños, informes de prueba, d) unidades de negocio;
documentación de la entrega; e) personas.
b) las líneas de referencia de la con-
Se deberían identificar las relaciones y
figuración o las premisas de cons-
dependencias adecuadas entre los ele-
trucción para cada entorno,
mentos de configuración para propor-
módulo hardware normalizado y
cionar el nivel de control necesario.
versión;
c) copia física maestra y bibliotecas Cuando sea necesario establecer alguna
electrónicas, por ejemplo: la biblio- trazabilidad, el proceso debería asegurar
teca definitiva de software; que se puede seguir el registro de los ele-
mentos de la configuración en todo su
d) las herramientas o paquetes usa-
ciclo de vida, desde los documentos de
dos para la gestión de la configu-
requisitos hasta los registros de entrega,
ración;
por ejemplo, utilizando una matriz de
e) licencias; trazabilidad.
f) componentes de seguridad, por
ejemplo: cortafuegos;
Como se aprecia entre los apartados del a) al j) de ISO/IEC 20000-2, se recomienda

una serie de tipos de elementos de configuración (CI) que deberían contemplarse
para cargarlos en la CMDB. Esta relación, aunque no está muy estructurada, aporta
indicaciones sobre qué categorías de elementos habrá que contemplar al diseñar la

CMDB.
El elemento de configuración se almacena en la CMDB bajo una ficha o registro
que permite catalogarlo, e incorpora la información específica que se haya decidido
que es útil para el proveedor de TI. En la figura 9.1.8 se muestra la parte genérica
de una ficha de un CI.
Elemento de configuración (CI)
Campos comunes en la ficha de un CI:

• ID. • Situación en la que se
Todos los CI encuentra el elemento en
• Nombre. el ciclo de vida estipulado.
tienen un núcleo
de información • Estado. • Indica que el CI no debe
común. ser usado.
• Categoría.
• Nombre de la persona/grupo
• Bloqueo. de trabajo responsable de
• Descripción. la administración del CI.
• Información puntual o
• Propietario (responsable).
importante de recoger
• Administrador. relacionada con el CI.
• Proveedor. • Identificador de elemento

único.
• Marca del producto.
• Nombre del entorno
• Comentarios. donde se encuentra el CI:
desarrollo, integración,
• Único. producción
• Entorno. • N.º de veces máximo que
puede existir un elemento
Según el tipo • N.º máximo de instalaciones.
no único. Sólo se aplica
de CI (servidor,
a elementos no únicos.
red, servicio, Campos adicionales según el tipo de CI: (Instancias, licencias, …)
persona, etc.)
se necesitará • ......
información
• ......
específica.
• ......
Fuente: Libros ITIL Soporte de Servicio y Transición del Servicio publicados por OGC, y Telefónica.
Figura 9.1.8. Ficha ejemplo de un elemento de configuración

CMDB
Como ejemplo, en la figura 9.1.9 se muestran los campos adicionales de un CI tipo

servidor.
CI tipo servidor
Campos comunes en la ficha de un CI:

• ... (véase la figura anterior).
Campos adicionales según el tipo de CI:

• Número de serie.
• Modelo.
• Clase de servidor.
• N.º de procesadores.
• Tipo de procesador.
• Tipo de memoria.
• Tamaño de la memoria.
• Velocidad del procesador.
• Dirección IP.
• Hostname.
• Capacidad almacenamiento local.
• Está en alta disponibilidad.
• N.º de interfaces de red.
• Tipo de interface.
• “MAC Address ”.
Figura 9.1.9. Campos adicionales para un CI tipo servidor hardware
En relación a la nomenclatura identificativa de los CI, se deben predefinir los códi-

gos de clasificación para que el sistema sea operativo. Las recomendaciones exis-
tentes convergen en que:
• El identificador sea constante, que no varíe a lo largo de la vida del elemento
(desde su registro, a su enajenación).
• La identificación debe ser, por supuesto, única y, si es posible, interpretable

por los usuarios.
• Este código debe ser utilizado en todas las comunicaciones referentes a cada
CI y, si es posible, debe ir físicamente unido al mismo (mediante una eti-
queta de difícil eliminación).
• La codificación no sólo debe ser utilizada para componentes de hardware,
sino también para la documentación y el software.
Hay muchas alternativas y para gustos no hay nada escrito. Lo más sencillo es esta-
blecer una clave con un número secuencial precedido de un acrónimo de categoría
o clasificación dentro de la CMDB, en el máximo nivel de abstracción posible. Por
ejemplo “HW001001” (correspondiente a la categoría hardware). Otros prefieren
incorporar alguna característica del CI a la clave para hacerla más inteligible, pero
esta característica debería ser constante durante la vida del CI, por ejemplo
“HWSER001001” (correspondiente a un servidor en la categoría HW).
La base de datos de gestión de la configuración (CMDB)

La CMDB es una base de datos que almacena información relativa a elementos de
la configuración (CI), tanto de los servicios, como de elementos de infraestructura
de TI y sus relaciones, entre ellos también están los SLA establecidos con el cliente.
Sobre la CMDB hay que contemplar los aspectos siguientes:
Diseño de la CMDB. Documento resultante de la actividad de la planificación de
la configuración que contiene el diseño de la CMDB, es decir, el diseño lógico
de la base de datos: alcance y profundidad, estructura general, tablas, relaciones,
atributos de los CI, estados de un CI, etc. Es necesario predeterminar la estructura
de la CMDB de manera que:
• Los objetivos sean realistas: una excesiva profundidad o detalle puede sobre-
cargar de trabajo a la organización y resultar, a la larga, en una dejación de
responsabilidades. En general cualquier servicio o proceso es susceptible
de ser incluido en la CMDB, pero unos objetivos en exceso ambiciosos pueden
resultar contraproducentes.
• La información sea suficiente: debe existir, al menos un registro de todos los
sistemas críticos para la infraestructura de TI.
Alcance. En primer lugar se debe determinar qué sistemas y componentes de TI se

van a incluir en la CMDB:
CMDB
• Es esencial incluir, al menos, todos los sistemas de hardware y software impli-

cados en los servicios críticos.
• Se debe determinar qué CI deben incluirse, dependiendo del estado de su ciclo
de vida. Por ejemplo, pueden obviarse componentes que ya han sido retirados.
• Es recomendable incorporar, al menos, la documentación asociada a la
estructura organizativa, los proyectos, los SLA, los contratos con suministra-
dores (UC) y las licencias.
Profundidad y nivel de detalle. Una vez determinado el alcance es necesario esta-

blecer la profundidad (tipos de CI que se deben contemplar dentro de una catego-
ría) y el nivel de detalle de la información asociada a un tipo de CI, como:
• Los atributos que describen a un determinado CI.
• Tipo de relaciones lógicas y físicas registradas entre los diferentes CI.
• Subcomponentes que se deban registrar independientemente.
Por ejemplo, en el caso de los ordenadores de sobremesa en la CMDB se podría

seleccionar:
• Atributos: fecha de compra, fabricante, procesador, sistema operativo, pro-
pietario, estado, coste, etc.
• Relaciones: conexión en red, impresoras conectadas, departamento, etc.
• Profundidad: memoria, disco, tarjetas gráficas, software instalado, tipo moni-
tor, etc.
En la figura 9.1.10 se muestra un boceto del diseño de una CMDB.

La estructura de la CMDB normalmente contemplará las siguientes categorías :
• Hardware. Servidores, almacenamiento, equipos de comunicación, ordena-
dores personales, impresoras, etc.
• Software. Aplicaciones que forman los servicios, productos y paquetes soft-
ware, herramientas de desarrollo, herramientas técnicas de monitorización y
de gestión, software ofimático, etc.
• Documentación. Organizativa, operaciones, técnica, etc.
• Servicio. Servicios de TI, servicios internos, servicios de terceros, etc.
• Activo de información. Bases de datos, archivos que contienen datos per-
sonales, manuales de usuarios, material de formación, procedimientos de
Figura 9.1.10. Diseño ejemplo de una CMDB
trabajo, planes de continuidad, etc. Contratos, documentación de la organi-

zación, correos electrónicos, etc.
• Contrato. SLA o acuerdos con clientes, OLA o acuerdos internos, UC o
contratos con suministradores.
• Persona. Personal de TI, directivos de la empresa, personal subcontratado,
personas de contacto de suministradores, de vigilantes de seguridad, perso-
nal de servicios, personal de limpieza, etc. A efectos del proceso de gestión
de la seguridad de la información, puede ser necesario tener una relación
exhaustiva de personas propias o ajenas que habitualmente tienen acceso a
las instalaciones o sistemas de la empresa.
• Localización. Edificios, centros de datos, sistemas de climatización, siste-
mas de alimentación eléctrica, sistemas de detección de incendios, etc.
• Entidad lógica. Clusters, instancias de servidores virtualizados, etc.
CMDB
En organizaciones grandes, la CMDB se suele formar como un conjunto de bases

de datos distribuidas, implementadas físicamente en equipos y localizaciones dis-
tintos, pero continúan formando una única entidad lógica. En la literatura, a este
tipo de CMDB se le suele denominar federada (FCMDB).
Existe también el concepto de base de datos de gestión de activos (asset manage-
ment data base) destinada a la gestión contable del inventario. La base de datos de
activos se relaciona con la CMDB normalmente por medio del identificador del
elemento de configuración mantenido de forma común en ambas bases de datos.
Interesa conseguir la trazabilidad de la información financiera de los CI, aun
cuando no resida físicamente en la CMDB.
Una faceta muy importante a exigir a la herramienta que soporta la CMDB es su
facilidad para integración con otros productos, tanto para la carga de datos, como
para integrarse en otras herramientas, ya que la CMDB acaba teniendo interfaces
con todo tipo de herramientas existentes. Así, la CMDB deberá integrarse con:
• Gestión del incidente.
• Gestión del cambio.
• Gestión de informes.
• Gestión de inventarios.
• Autodescubrimientos.
• Herramientas web de visualización gráfica de las configuraciones.
Si bien queda fuera del ámbito de responsabilidad de la gestión de la configuración,

es importante hacer notar la existencia de soluciones o herramientas que, a partir
de la información contenida en la CMDB, proporcionan una visión gráfica de los
servicios de TI (service view). Estas soluciones, por otro lado, también son capaces
de integrarse con herramientas de monitorización a efectos de ofrecer en tiempo
real un cuadro de mando de monitorización de los servicios de TI. Esta vista suele
ser navegable, pudiéndose descender gráficamente entre los elementos que compo-
nen un servicio, hasta llegar al componente que esté fallando.
Los cambios realizados en los elementos de configuración y sus relaciones, provo-
cados por los cambios habituales en la infraestructura (petición de cambio o RFC),
deben automatizarse en la medida de lo posible. Además, se debe dejar un registro
cruzado, tanto en CI con el RFC que lo ha modificado, como en el RFC con los
CI que modifica. Así, desde dicho elemento de configuración, se podrá acceder a
un histórico de las solicitudes de cambios que han provocado las modificaciones de
dicho elemento. Dicha trazabilidad entre la petición de cambio y el CI afectado es,

a menudo, una evidencia solicitada por cualquier auditoría para constatar la inte-
gridad del sistema de gestión. Y aquí, la consistencia de datos es ineludible.
Así pues, una CMDB tiene que estar bien integrada con su entorno, con modelado
gráfico de relaciones entre CI y con mecanismos de asignación masivos basados en
clasificadores o reglas de negocio, pues son muy útiles para eliminar tareas monó-
tonas en el mantenimiento de sus contenidos.
La biblioteca de software definitivo (DSL)

La biblioteca de software definitivo (DSL, Definitve Software Library) es un reposi-
torio en el que se almacena una copia de todo el software instalado en el entorno de
TI. En ITIL v3 se la ha denominado como biblioteca de medios definitivos (DML,
Definitive Media Library).
Este sistema de almacenamiento, normalmente estará formado por una base de
datos que tiene las fichas de catalogación de todos los CI software, un conjunto
de directorios compartidos que almacenan los archivos con el software original y un
conjunto de armarios que contienen los CD originales del fabricante y un justifi-
cante impreso de la propiedad de la licencia (en los casos en los que se tuviera).
Contiene los originales controlados de todo el software de la organización. La DSL
deberá contener las copias finales del software adquirido (junto con sus licencias o
información), así como el software de desarrollo propio. Los originales de toda la
documentación de un sistema también se almacenarán en la DSL en forma digital.
Únicamente debe aceptarse en la DSL el software autorizado.
En realidad, este sistema de almacenamiento puede constar de una o más bibliotecas
de software o sistemas de almacenamiento de archivos que deberían estar separados
de los sistemas de almacenamiento de archivos de desarrollo, pruebas y producción.
La DSL almacena tanto el código fuente de los programas, como los ejecutables y
su documentación. También incorpora el software comprado a los fabricantes (sis-
tema operativo, gestor de bases de datos, etc.) y todas las actualizaciones del mismo
instaladas. Esto incluye también a los controladores de dispositivos y documenta-
ción asociada. Incorpora la parametrización realizada en los productos y aplicati-
vos, así como, todas las configuraciones necesarias a realizar en la planta instalada
durante la etapa de integración y pruebas. No hay que olvidar también la necesidad
de registro del software que se descargue de Internet (gratuito o de pago).
La DSL debe contener el histórico completo de versiones de un mismo software
para proporcionar la versión necesaria en el caso de que se deban implementar los
planes de marcha atrás.
CMDB
En la figura 9.1.11 se muestran los principales elementos que se deben considerar

en el diseño de la DSL.
Diseño de la DSL
Gestor de la
configuración
Ficha CI CI CI CI
del CI CI CI
CICMDB CI
Diseño de la DSL: software CI CI CI CI CI
• Definir nomenclatura, etiquetado

y ficha catalográfica.
• Definir ámbito, alcance. CI
• Definir tipos de CI software a incluir. software
• Requisitos herramienta DSL y Archivo físico Archivo electrónico
del almacenamiento físico.
• Período retención del software.
• Procedimientos actualización.
• Relación con procesos de cambio
y de entrega.
• Relación con el área de proyectos
desarrollo software.
• Procedimientos de auditoría.
DSL
Biblioteca de software definitivo
• Plan de capacidad y de continuidad.
Figura 9.1.11. Elementos a considerar en el diseño de la DSL
La DSL y la CMDB deben estar cubiertas por el plan de continuidad de TI y con-

templadas como los primeros elementos a recuperar, pues sin ellas será imposible
restaurar los servicios.
También se deberá realizar la gestión de la capacidad de la DSL, para almacenar
todas las actualizaciones de software que envían los fabricantes. No hay que pasar
por alto el espacio necesario en armarios para clasificar los DVD y CD, y los
manuales de los fabricantes, aunque la tendencia de la industria es ir reduciendo el
soporte físico. El almacenamiento de los justificantes de las licencias para propósi-
tos de auditorías posteriores, también requiere su “arte”, debido a los diferentes
formatos en que se facilitan (un código electrónico, una pegatina en la caja, un
documento impreso, etc.). La DSL debe almacenarse en un entorno seguro y es
conveniente que se realicen copias de seguridad periódicas de la parte digital.
En empresas de tamaño medio o grande, lo lógico es utilizar un producto del mer-
cado para soportar la DSL. Para el control de los códigos fuente de los aplicativos de
la empresa, lo habitual es utilizar para la DSL la misma instalación de la herramienta

de “control de versiones” utilizada por los proyectos de desarrollo. Pero se debe man-
tener una rigurosa separación lógica entre el control de las versiones del desarrollo y
el software instalado en producción.
Control de la configuración (registrar y actualizar)

Despista un poco que bajo el término de control se esconda toda la actividad de carga
y actualización de datos. Hay que leer un poco entre líneas para darse cuenta de este
aspecto, pues las Normas ISO/IEC 20000 se centran en especificar requisitos para
que la información se incorpore de una forma controlada a la CMDB y a la DSL.
La actividad de control de la configuración realiza la carga y actualización de la
información sobre los CI en la CMDB y almacena los CI software en la DSL. Ade-
más, debe garantizar que la información es fiable.
Hay que tener en cuenta que una correcta gestión de la configuración necesita la
colaboración de todo el personal de TI para mantener actualizada la información
almacenada. Para lograrlo, el gestor de la configuración nombrará la figura de los
titulares de los elementos de configuración, que son los responsables de que la infor-
mación de los CI esté correctamente actualizada (servidores, elementos de red, etc.).
Las mejores prácticas recomiendan que los resultados de las herramientas de auto-
descubrimiento se almacenen en una base de datos temporal, y no se carguen direc-
tamente en la CMDB. Así, se evita la introducción de errores en la información.
Posteriormente, con un proceso supervisado se realiza la conciliación de ambas
bases de datos y se analizan las inconsistencias.
UNE-ISO/IEC 20000-1
Los procedimientos de control de configuración deben asegurar que se mantiene la

integridad de los sistemas, servicios y componentes de servicio.
UNE-ISO/IEC 20000-2
El proceso debería garantizar que sólo los Ningún elemento de la configuración se

elementos de la configuración autoriza- debería añadir, modificar, reemplazar o
dos e identificables son aceptados y regis- eliminar/retirar sin la documentación de
trados desde su recepción hasta su baja. control apropiada, por ejemplo: apro-
CMDB
bación de la solicitud de cambio, infor- b) proporcione algún medio de recu-

mación actualizada de la versión. peración ante desastres;
Para proteger la integrad de los sistemas, c) permita la recuperación contro-
servicios e infraestructura, los elementos lada de una copia del maestro
de la configuración se deberían mantener controlado, por ejemplo: software.
en un entorno seguro y adecuado que:
a) los proteja de accesos no autori-
zados, cambios o corrupción, por
ejemplo: virus;
La gestión de la configuración debe estar puntualmente informada de todos los

cambios y adquisiciones de componentes para mantener actualizadas la CMDB y la
DSL. Igualmente debe estarlo en lo relativo a cualquier cambio realizado en todo
tipo de elemento instalado.
El registro de los componentes hardware se debe iniciar desde el mismo momento
de la aprobación de su compra y debe mantenerse actualizado su estado en todo su
ciclo de vida. Debe haber un registro auditable de todas las actualizaciones. Espe-
cialmente, debe estar correctamente registrado y almacenado todo el software “en
producción” y su documentación.
Las tareas de control parten de CI ya etiquetados y deben centrarse en:
• Registrar los CI nuevos y sus versiones, tanto en la CMDB como en la DSL.
• Actualizar el registro de los CI.
• Proteger la integridad de las configuraciones.
• Asegurar que todos los componentes están registrados en la CMDB.
• Asegurar que todo componente software y su documentación están almace-
nado en la DSL.
• Monitorizar el estado de todos los componentes.
• Comprobar y actualizar las interrelaciones entre los CI.
• Informar sobre el estado de las licencias.
En pequeñas organizaciones a veces es conveniente combinar en una persona la

gestión de la configuración con la gestión del cambio, para simplificar el bloque de
control. La coordinación entre ambos procesos es una factor crítico para el éxito y
ésta unificación puede resultar beneficiosa en aquellos casos en el que el volumen
de la infraestructura no justifica la designación de funciones separadas.
Seguimiento del estado de configuración e informes

(informar)
La actividad de seguimiento del estado enmascara la principal funcionalidad de este
proceso, que es ser consultado. Así, la actividad se centra en proporcionar a toda
la organización la información disponible sobre los CI, bien sean las fichas de la
CMDB o los archivos de la DSL. El personal de la organización de TI podrá obtener
datos de la configuración, bien mediante petición de información a gestión de la
configuración, o bien mediante consulta directa de la CMDB. Normalmente, son las
propias herramientas de gestión (incidente, problema, cambio, nivel de servicio, etc.)
las que se integran con la CMDB para mostrar la información de configuración de
forma integrada en sus pantallas de gestión.
Además, esta actividad genera y distribuye, de forma regular, informes sobre el
estado de la configuración, en los que se muestran el historial de cambios y la ver-
sión actual de cada uno de los CI bajo control. También, en esta actividad se calcu-
lan las métricas y se generan los informes necesarios para controlar el correcto fun-
cionamiento del proceso de gestión de la configuración.
UNE-ISO/IEC 20000-1
La gestión de la configuración debe proporcionar información al proceso de gestión

del cambio sobre el impacto de un cambio solicitado sobre la configuración del ser-
vicio y de la infraestructura. Los cambios en los elementos de configuración deben
ser fáciles de identificar y auditables cuando sea apropiado, por ejemplo para cam-
bios y movimientos en el software y el hardware.
Antes de un paso al entorno real, debe establecerse una línea de referencia de los
elementos de configuración correspondientes.
UNE-ISO/IEC 20000-2
Los registros de la configuración se debe- Esto debería permitir el seguimiento de

rían mantener actualizados y con la pre- los cambios en los elementos de la confi-
cisión adecuada para reflejar los cam- guración a través de sus diferentes esta-
bios en el estado, localización y versión dos, por ejemplo: solicitado, recibido, en
de los elementos de la configuración. pruebas de aceptación, activo, bajo cam-
bio, retirado y eliminado.
El seguimiento del estado debería propor-
cionar información sobre los datos actua- La información de la configuración se
les e históricos de cada elemento de con- debería mantener actualizada y disponi-
figuración a lo largo de su ciclo de vida. ble para: los planes, la toma de decisio-
CMDB
nes y la realización de cambios a las Los informes deberían cubrir:

configuraciones definidas.
a) las últimas versiones de los ele-
Cuando sea requerida, la información mentos de la configuración;
de la configuración debería estar acce-
b) la localización del elemento de
sible a: usuarios, clientes, suministrado-
configuración y, para el software,
res y socios para darles apoyo en sus
la localización de las versiones
planes y en la toma de decisiones. Por
maestras;
ejemplo, un proveedor externo de servi-
cios podría poner accesible su informa- c) interdependencias;
ción de la configuración a los clientes y
d) historia de la versión;
a otras partes, para dar soporte a los
procesos de gestión del servicio del resto e) estado de los elementos de la
de las partes implicadas en un servicio configuración que conjuntamente
completo extremo a extremo. constituyan:
Los informes de gestión de la configura- 1) la configuración del servicio o
ción deberían estar disponibles para del sistema;
todas las partes correspondientes. Los
2) un cambio, una línea de refe-
informes deberían cubrir: la identifica-
rencia, un paquete de instala-
ción y el estado de los elementos de la
ción o una entrega;
configuración, sus versiones y la docu-
mentación asociada. 3) una versión o una variante.
La información relativa a los indicadores de gestión del proceso permite evaluar el

volumen de objetos manejados, su grado de implantación y efectividad, así como,
el cumplimiento de los acuerdos de nivel operativo (OLA) establecidos.
Es imprescindible elaborar informes que permitan evaluar el desempeño de la ges-
tión de la configuración, tanto para conocer la estructura y adecuación de la
CMDB y la DSL, como para aportar información a otras áreas de TI.
Otra actividad que se debe realizar es la generación de las líneas base, que permiten
obtener una fotografía del estado de la configuración de un entorno en un
momento del tiempo (por ejemplo, antes de una entrega), con el objeto de facilitar
la marcha atrás en caso de que el paso a producción no sea satisfactorio.
Verificación y auditoría de la configuración

Se deben formalizar procedimientos de verificación y auditoría al objeto de asegurar
que el contenido de la CMDB y de la DSL son exactos y completos. Se compararán
los CI registrados en la CMDB con respecto a los componentes lógicos y físicos en
la infraestructura, permitiendo así identificar las desviaciones respecto a la realidad.
UNE-ISO/IEC 20000-1
Los procedimientos de auditoría de la configuración deben incluir el registro de defi-

ciencias, el lanzamiento de acciones correctivas y la comunicación de su resultado.
UNE-ISO/IEC 20000-2
Los procesos de verificación y auditoria, Periódicamente se deberían realizar audi-

en sus aspectos físicos y funcionales, se torías de la configuración, antes y des-
deberían planificar y se debería realizar pués de un cambio importante, después
una comprobación para asegurar que de un desastre y a intervalos aleatorios.
los procesos y recursos adecuados están
Las deficiencias y las no conformidades
establecidos para:
se deberían registrar, evaluar e iniciar
a) proteger las configuraciones físi- una acción correctiva, actuar sobre
cas y el capital intelectual de la ellas; y se debería realimentar a las par-
organización; tes correspondientes así como estable-
b) asegurar que el proveedor del cer un plan de mejora del servicio.
servicio tiene el control de sus Nota: Normalmente hay dos tipos de auditoria
configuraciones, las copias maes- de la configuración:
tras y las licencias; a) auditoria funcional de la configuración:
c) garantizar que la información de un examen formal para verificar que un
elemento de configuración ha alcan-
la configuración está actualizada, zado el rendimiento y características
controlada y es visible; funcionales especificadas en sus docu-
mentos de configuración;
d) asegurar que un cambio, una
entrega, un sistema o un entorno b) auditoria física de la configuración: un
examen formal de la configuración
es conforme a los requisitos con- “según sale de fábrica” de un elemento
tratados o especificados y que los de configuración para verificar su con-
registros de la configuración son formidad con sus documentos de confi-
exactos. guración del producto.
El objetivo de las auditorías es asegurar que la información registrada en la CMDB

y la DSL coincide con la configuración real.
La información recopilada por las herramientas de gestión remota y de autodescu-
brimiento de los elementos de configuración de hardware y software puede ser utili-
zada para verificar la CMDB y la DSL. No obstante, es necesario complementar
estos datos con auditorías manuales. Éstas deben realizarse con cierta frecuencia y
al menos:
• Tras la implementación de una nueva CMDB o DSL.
CMDB
• Antes y después de grandes cambios en la infraestructura.

• Cuando existen sospechas de que la información almacenada es incorrecta o
incompleta.
Las auditorías deben dedicar especial atención a aspectos como:

• El uso correcto de la nomenclatura en los registros de los CI.
• La comunicación con la gestión del cambio: información sobre RFC, cam-
bios realizados, etc.
• El estado actualizado de los CI.
• El cumplimiento de los niveles de alcance y detalle predeterminados.
• La actualización y grado de completitud de la DSL.
• La adecuación de la estructura de la CMDB con la de la estructura de TI real.
Entre la documentación generada cabría destacar:

• Las desviaciones entre la información almacenada (CMDB o DSL) y la obte-
nida de las auditorías de configuración.
• Los costes asociados al propio proceso.
• Los sistemas de clasificación y nomenclatura utilizados.
• Los informes sobre la configuración no autorizada y si están amparadas por
licencias.
• La calidad del proceso de registro y clasificación.
• La información estadística.
Inconsistencias y no conformidades. Es la información relativa a las distintas

inconsistencias encontradas como resultado de las actividades de verificación y
auditoría del estado de la configuración. Estas inconsistencias son provocadas fun-
damentalmente por la implementación de CI no autorizados o que no van acom-
pañados de la documentación requerida.
Las inconsistencias se pueden detectar desde cualquier proceso, pero habitualmente
es en la gestión de incidentes y la operación donde se suelen identificar el mayor
número de ellas. Es recomendable establecer un flujo de relación entre estos proce-
sos, proveedores de mejoras, y el de configuración para poder trazar una revisión
de cumplimiento, tanto los registros de inconsistencias detectados, como los meca-
nismos para obtenerlos.
Las auditorías físicas y periódicas, también deben alimentar los registros de opor-
tunidades de mejora, y arrancar las consiguientes acciones correctivas.
La detección de inconsistencias debe llevar aparejada una concienciación de todos
los implicados sobre la importancia y gravedad (impacto) que puede representar
una inexactitud en la información recogida. Así, no sólo se favorece la mejora con-
tinua, sino que además, se garantiza la solvencia de la CMDB y la DSL, haciéndo-
las cada vez más robustas y fiables.
En esta actividad se evalúa el proceso en base a las métricas e informes de gestión,

y consecuentemente se proponen mejoras al mismo. También, se debe hablar con
todos los participantes para detectar mejoras al mismo.
Se debe poner foco en la automatización progresiva de las actividades de carga y
descubrimiento. Dado que la configuración es un proceso que suministra informa-
ción a toda la organización, se debe ir completando progresivamente la integración
de la CMDB con el resto de herramientas de gestión del proveedor de TI.
Si este proceso se ha implantado siguiendo las recomendaciones, se habrá iniciado
de una forma sencilla, por tanto, habrá que contemplar una mejora progresiva: en
primer lugar, del poblado de la CMDB y, en segundo lugar, incrementando el
alcance y la profundidad.
Todas estas actividades de mejora tienen un coste y un esfuerzo nada despreciable
que habrá que contemplar en los presupuestos anuales del proveedor de TI. Los
beneficios de tener una información completa y fiable sobrepasan con creces el
coste necesario para alcanzarlo.
Como con el resto de los procesos, las propuestas de mejora de este proceso se
deben incorporar al plan general de mejora de gestión del servicio (véase el capí-
tulo 4), para ser analizadas y desplegadas en un programa único de mejora.

Dado que la gestión de la configuración es un proceso interno de TI, no visible
para el negocio, no suele aportar indicadores globales de TI (KGI de TI). En este
caso, las métricas del proceso se centrarán en informar al CIO y al responsable del
proceso. Contemplarán aspectos como:
• Calidad del dato: el número de cambios en la CMDB por CI incorrectos o el
porcentaje de CI que han pasado satisfactoriamente la última auditoría.
CMDB
• Volumen o actividad: número de CI, incremento de CI en el último período,

el número medio de accesos a la CMDB, número de líneas base proporcio-
nadas, etc.
• Eficiencia: el porcentaje de CI con actualización automática.
• Grado de cobertura y calidad del software por parte de la DSL.
En el gráfico de la figura 9.1.12 se muestra el resumen de los indicadores más rele-

vantes para este proceso seleccionados por un grupo de trabajo de itSMF España.
de itSMF España

Como en el resto de los procesos, los roles intervinientes en el proceso se estructu-
ran en los roles propios del proceso y los roles ajenos al proceso.
• El gestor de la configuración (gestor del proceso o process manager) es el res-
ponsable del día a día de la actividad del proceso. En este caso identifica,
aprueba y controla la actualización de los elementos de configuración. Tiene
bajo su control la CMDB y la DSL, vela por el acceso a la información de

toda la organización, se encarga de las auditorías de la configuración, etc.
• Los administradores o las personas encargadas del soporte al proceso, ayu-
dan al gestor de la configuración en toda la actividad.
• El administrador de la CMDB y DSL, es un perfil técnico que administra la
base de datos.
• Los titulares de elementos de configuración, personal de la organización de
TI que vela por la información de configuración de los CI asignados.
Los roles ajenos que son relevantes en este proceso son los siguientes.
continua del mismo. Todo ello de una forma integrada con el modelo de ges-
tión del proveedor de TI incorporado en el SGSTI.
• El responsable de la gestión del cambio debe proporcionar información
de todos los cambios en los CI a los que se ha asignado el control de uno
o varios elementos de configuración. Será un miembro de la organiza-
ción de TI especializado en un ámbito tecnológico, y con el conoci-
miento requerido para identificar y mantener los CI que estén bajo su
área de control.
Los roles de mayor relevancia que participan en el proceso de gestión de la confi-

guración se representan en la figura 9.1.13.
Resumen
Sin una buena información de la configuración es imposible alcanzar una eficiencia
y madurez en la gestión de las TI. Una información fidedigna y completa sobre la
infraestructura de TI, sus servicios y la organización que los presta, son los cimien-
tos para reducir los incidentes, ser ágiles en la provisión de peticiones, evitar erro-
res en los cambios, etc.
De una forma paulatina pero constante, en la implementación de la gestión del
servicio hay que dedicar esfuerzos importantes a aglutinar y organizar la informa-
ción sobre la configuración de TI. Por ello, es uno de los primeros procesos que
CMDB
Roles del proceso
Responsable de la
Gestor de la
SGSTI configuración
Administrador de
la CMDB y DSL
Propietario del
modelo (SGSTI)
Administrador y
soporte del proceso
de configuración
Titulares de elementos
de configuración
Gestor del cambio
Figura 9.1.13. Roles del proceso de gestión de la configuración
se suele implementar, aunque por su laboriosidad no se le puede calificar de éxito

rápido.
La CMDB no se limita a una mera enumeración del stock de piezas, sino que nos
brinda una imagen global de la infraestructura de TI de la organización, con todos
sus elementos.
En ISO/IEC 20000, al igual que en ITIL v3, la gestión de la DSL se encarga a la
gestión de la configuración, a diferencia de ITIL v2, que estaba bajo la responsabi-
lidad de la gestión de la entrega.
Beneficios
Algunos de los beneficios de alcanzar una correcta gestión de la configuración son
los siguientes:
• Resolución más rápida de los incidentes y los problemas, que redunda en
una mayor calidad de servicio. Una fuente habitual de problemas es la
incompatibilidad entre diferentes CI (por ejemplo, drivers desactualizados,
etc.). La detección de estos errores sin una CMDB actualizada alarga consi-
derablemente el ciclo de vida de un incidente o de un problema.
• Disponer de los fuentes precisos y actualizados cuando empieza un pro-
yecto de evolución, así como, tener un correcto control de los módulos
que cada equipo de desarrollo está modificando resulta esencial para aho-
rrar esfuerzos inútiles y que varios equipos trabajen sobre software desac-
tualizado.
• De la misma forma, no tiene precio la eficacia y seguridad que le otorga a un
equipo de desarrollo que comienza un proyecto, el conocer con precisión la
configuración real del entrono de producción en donde se explotará el apli-
cativo.
• Una gestión del cambio más eficiente. Es imprescindible para conocer la
estructura previa, analizar el impacto y diseñar un cambio que no genere
nuevas incompatibilidades o incidentes.
• Reducción de costes. El conocimiento detallado de todos los elementos de
configuración permite, por ejemplo, eliminar duplicidades innecesarias y
ahorrar tiempo en repetidas búsquedas de información.
• Control de licencias. Al contrario de lo que pasaba antaño, que el control
de licencias acarreaba el descubrimiento de software ilegal, hoy día tener un
buen control de las licencias puede traer importantes ahorros en costes,
por licencias no utilizadas, por mantenimientos innecesarios, por duplici-
dades, etc.
• Mayores niveles de seguridad. Una CMDB y DSL actualizadas permiten,
por ejemplo, detectar vulnerabilidades en la infraestructura.
• Mayor rapidez en la restauración del servicio. Si se conocen todos los ele-
mentos de configuración y sus interrelaciones será mucho más sencillo recu-
perar la configuración de producción en el tiempo más breve posible.
CMDB
• Realice un esquema con los dos primeros niveles de una CMDB para
su organización.
• ¿Qué campos incluiría en la ficha del CI tipo servicio?
• ¿Cómo se organiza en su empresa el paso de los componentes soft-
ware, que suelen mantener de los equipos de desarrollo (control de
versiones), a la DSL?
1
9.2. Gestión del cambio 661
9.2. Gestión del cambio
Figura 9.2.1. Esquema general del proceso de la gestión del cambio
Vivimos en una época de continuos cambios. Es el propio mercado el que imprime

al negocio un ritmo constante de transformación para sacar nuevos productos, para
ser competitivos en costes o para la excelencia en las formas de gestionar. Vemos
cómo la informática, que inició su andadura automatizando tareas humanas, es
cada vez más importante para la supervivencia del negocio.
La organización de TI debe ser capaz no sólo de mantener este ritmo exigido por
el mercado al negocio, sino que además debería situarse al frente de la batalla, pro-
poniendo nuevas soluciones a lo existente, nuevos productos y nuevas vías de inter-
acción con el mercado; para, en definitiva, encontrar la difícil senda de aportar
valor al negocio.
Pero, el ritmo acelerado de evolución que debe mantener TI para responder a las
necesidades del negocio, tiene un severo lastre, los cambios son la fuente principal
de incidentes, de inconsistencias en la información y de trabajo. Los cambios en los
servicios provienen de numerosas fuentes: la incorporación de nuevos servicios, la
mejora de los existentes, la resolución de incidentes o de problemas, por necesidad
de cumplir un mandato legal, etc.
En este escenario, el proceso de la gestión del cambio se convierte en una pieza

estratégica esencial para imprimir la agilidad necesaria a la evolución, mientras
se mantiene un control férreo sobre la estabilidad y robustez de los servicios.
Por esta razón, este proceso es uno de los primeros en implementarse (véase la
figura 9.2.1).
Formalmente, la gestión del cambio es el proceso con la responsabilidad sobre el
control y tratamiento de los cambios en cualquier elemento que forme parte de los
servicios de TI, minimizando el riesgo y velando por la eficacia. En la figura 9.2.2
se presenta una visión introductoria al proceso.
Proceso de gestión del cambio Qué aporta:
• Mayor fiabilidad de los servicios, al

Definición: minimizar el impacto sobre la calidad
del servicio por los cambios.
Proceso responsable del control y
tratamiento de los cambios en los • Asegurar el empleo de métodos para
servicios y en la infraestructura TI. manejar eficaz y eficientemente un
alto volumen de cambios.
Objetivo: • Implantar una gestión integral que

proporcione una visión conjunta del
Asegurar que todos los cambios son impacto de los cambios en el negocio.
registrados, evaluados, aprobados,
implementados y revisados de una • Realizar cambios en los servicios de
manera controlada. manera ordenada y estructurada,
coordinando la realización de
actividades.
• Garantizar que todos los cambios son

registrados adecuadamente.
Figura 9.2.2. Introducción al proceso de gestión del cambio
La gestión del cambio debe trabajar para asegurar que los cambios:
• Son necesarios y están justificados.
• Se llevan a cabo sin perjuicio de la calidad del servicio de TI.
• Están convenientemente registrados, clasificados y documentados.
• Cumplen los plazos acordados.
• Han sido cuidadosamente probados en un entorno de prueba.
• Se realizan con eficiencia.

• Se ven reflejados en la CMDB.
• Pueden deshacerse mediante planes de marcha atrás del cambio, en caso de
un incorrecto funcionamiento tras su implementación.
Fiabilidad, agilidad y eficiencia, son quizá los tres principios directores que debe
regir la gestión del cambio. Fiabilidad para evitar errores y fallos, agilidad para ser
capaces de cambiar los servicios respondiendo al “time to maket” que requiere la
empresa, y eficiencia para realizar el proceso incurriendo en costes mínimos, como
se muestra en la figura 9.2.3.
Figura 9.2.3. Principios directores que deben regir la gestión del cambio
El equilibrio entre estos tres mandatos permitirá que, el control y rigor que impone
este proceso en la organización para conseguir la fiabilidad y reducir el riesgo, se
pueda realizar incurriendo en el mínimo coste organizativo. Si se adoptan procedi-
mientos excesivamente restrictivos, se mejora la fiabilidad, pero se dificultan los
cambios y la organización se vuelve lenta. Si por el contrario el proceso de cambio
se trivializa, se provoca una falta de estabilidad en el servicio que infringirá impor-
tantes costes a causa de incidentes y la imposibilidad de controlar su calidad.
En el diseño del proceso y de las tareas que incluye hay que tener en cuenta el volu-
men de cambios que se tendrán que gestionar, pues una organización grande (por
ejemplo, de 10.000 usuarios y 500 servidores) suele gestionar entre 70 y 100 peti-
ciones de cambio ya formalizadas a la semana (sin contar los cambios estándar pre-
autorizados), por lo que, gran parte de la actividad del proceso se centra en contro-
lar que todos los involucrados en este flujo sin fin de cambios cumplan las reglas.
Disponer de una herramienta para su soporte es esencial.
También, es conveniente diferenciar las actividades propias de la gestión del cam-
bio de las actividades específicas de la gestión de los proyectos que se encargan de
la construcción de los grandes cambios. El primero hace referencia al proceso
de control de toda la actividad que pueda impactar en los servicios, y el segundo se
encarga de engranar la actividad necesaria para construir o modificar las aplicacio-
nes o plataformas que forman parte de un cambio específico. La gestión del cam-
bio se rige por ISO/IEC 20000, mientras que la gestión de proyectos utiliza disci-
plinas como PMBOK o PRINCE2.
Además, hay que considerar que la gestión del cambio es una parte esencial del pro-
ceso de creación de servicios (planificación e implementación de servicios nuevos o
modificados; véase el capítulo 5), pues da luz verde al inicio de la construcción y se
responsabiliza de la implantación del nuevo servicio.
Gestión del cambio tiene una estrecha relación con gestión de la entrega, pues cada
uno de los cambios aprobados debe ser implantado y desplegado por este último
proceso.
En la figura 9.2.4 se recoge un resumen de los elementos que intervienen el pro-
Los elementos principales que componen el proceso de gestión del cambio son los
siguientes:
Cambio. Acción específica y prevista que alterará o tendrá un efecto sobre los ser-
vicios o la infraestructura de TI. En general, es cualquier adición, eliminación,
modificación o movimiento de uno o más CI (elementos de configuración). En la
actividad habitual del proceso, los cambios se articulan en función de una serie de
criterios entre los que podemos considerar:
• Atendiendo a su alcance, complejidad o impacto:
– Gran cambio (macro).
– Cambio significativo (mayor).
– Cambio menor.
• Atendiendo a la forma en que se ejecuta el cambio:

– Cambio normal.
ACTORES SERVICIOS
CI
Documentación
HW SLAs
Promotores Comité de cambios
de los cambios Gestor del cambio (CAB) SW
Solicitud de cambio
(RFC)
Lista de cambios Gestionar la
planificados (FSC) mejora del proceso
Plan de pruebas
Informe de Aprobación Aprobación Comprobación

disponibilidad (PSA) construcción transición post-implantación
Figura 9.2.4. Elementos del proceso de gestión del cambio
– Cambio estándar.
– Cambio preautorizado.
– Cambio urgente o de emergencia.
Realmente cada organización va a determinar los tipos de cambio más adecuados a

sus necesidades. A continuación, se describen los más frecuentes:
• Cambios macro y mayor. Habitualmente se gestionan bajo una estructura
de proyecto. Son complejos y requieren la dedicación de bastantes recursos.
Suelen ser cambios que provienen del proceso de creación o evolución de
servicios. En estos casos, el cambio tiene gran importancia y suele tener un
impacto probable en otras partes de la organización, por lo que se aplica el
ciclo de vida del cambio hasta su último requisito. Son ejemplos, implantar
un nuevo servicio con toda su infraestructura, realizar una consolidación de
servidores, cambiar la arquitectura de los firewalls.
• Cambio menor. De impacto bajo y que requiere pocos recursos. Suelen
recorrer un ciclo de vida mucho más corto, eliminándose actividades de con-
trol que no tienen sentido para estos cambios menores. Por ejemplo, instalar
un servidor nuevo.
• Cambio preautorizado. Cambio recurrente que se gestiona por delegación
siguiendo unas reglas predeterminadas. Para cambios de escasa importancia,
recurrentes o que se repiten periódicamente, pueden acordarse procedimien-
tos estándar que no requieran la aprobación expresa de la gestión del cambio
(cambios preautorizados). Una vez definida esta tipología, permite una ges-
tión más rápida y eficiente de cambios de bajo impacto en la organización de
TI. Por ejemplo, establecer los perfiles de acceso de un nuevo empleado,
generar una nueva contraseña o instalar una aplicación en un PC.
• Cambio de emergencia. Establecen la forma de actuar cuando es impres-
cindible introducir un cambio de forma inmediata para solucionar una crisis
grave.
Clasificación de un cambio. Todo cambio debe ser clasificado para poder tratarlo
de la forma más adecuada posible. De forma similar a los incidentes y los proble-
mas, se establecen dos tipos de clasificaciones: la categoría que tipifica el contenido
del cambio y la prioridad con la que debe ser tratado:
• Categoría del cambio. Tipificación de un cambio según una clasificación
predefinida, que tendrá en cuenta el efecto del cambio en la organización
de TI en función de los recursos que se estimen necesarios para su implan-
tación.
• Prioridad del cambio. Valor que se asigna a la solicitud de cambio (RFC)
para indicar su importancia para la organización. Su objeto es el de asegurar
la adecuada asignación de recursos y determinar el plazo en el que se requiere
su ejecución. La prioridad dependerá de:
– El impacto del cambio. Medida del efecto sobre el negocio.
– La urgencia del cambio. Medida de plazo para la atención de un cambio.
Comité de cambios (CAB, Change Advisory Board). Comisión o grupo repre-

sentativo de TI y de la empresa, con autoridad y competencia para valorar y acon-
sejar la implementación de los cambios, desde los puntos de vista técnicos y de
negocio. Se reúne de forma regular para informar al gestor del cambio sobre la ido-
neidad de aprobar cada cambio. El CAB es convocado y liderado por el gestor del
cambio.
Gestor del cambio. Responsable de todo el proceso de gestión del cambio. Res-
ponsable último de que toda la actividad de cambios no impacte en los servicios y
de que se realice según lo establecido.
Herramienta de gestión del cambio. Es el conjunto de aplicaciones y bases de
datos necesarios para dar soporte informático al proceso.
Informe de disponibilidad prevista del servicio (PSA, Projected Service Availa-
bility). Es el documento utilizado en la gestión del cambio para describir el efecto
de los cambios sobre los niveles de disponibilidad definidos en los acuerdos de
nivel de servicio. El PSA muestra detalles de las variaciones de la disponibilidad en
los acuerdos de nivel de servicio, motivadas por el cambio programado propuesto.
gramación unificada de todos los cambios en curso, que recoge los detalles de los
cambios cuya implantación haya sido aprobada, así como las fechas propuestas para
su implantación. En ITIL v3 se ha pasado a denominar “lista de cambios” (change
schedule).
La FSC es controlada por el gestor del cambio y debe ser acordada con todas las
partes: los clientes, la gestión de nivel de servicio, el centro de servicio al usuario,
gestión de la disponibilidad, etc. Una vez acordada, el centro de servicio al usua-
rio debería comunicar a la comunidad de usuarios cualquier planificación o
tiempo adicional de parada para la implantación de cambios, utilizando para ello
los métodos más efectivos disponibles.
La FSC es una entrada esencial del proceso de gestión de la entrega.
Plan de pruebas del cambio. Documento que detalla todas las pruebas necesarias
que se realizarán en todas las etapas por las que pasa el cambio, desde las pruebas
durante la fase de construcción, las pruebas en la fase de implementación, hasta las
pruebas de aceptación final del cambio. El plan de pruebas se prepara en el ámbito
del proyecto.
Promotores de los cambios. Personas de la organización de TI que, a partir de
una necesidad de realizar un cambio, desencadenan la solicitud del cambio. En
cambios grandes o complejos, el cambio se gestionaría como un proyecto y el pro-
motor sería el jefe del proyecto.
Registro de cambios. Base de datos que contiene toda la información relativa a los
cambios en curso ya realizados o rechazados. Contiene las RFC, los detalles sobre
los elementos de configuración afectados, la historia del cambio, etc. El cambio se

registra a partir de la aceptación de la solicitud de cambio. Esta base de datos está
incluida en la herramienta para la gestión de cambios, que normalmente será una
suite o producto informático que cubra los procesos de resolución y de control de
los servicios.
Solicitud de cambio (RFC, Request For Change). Formulario utilizado para pro-
poner un cambio en cualquier componente de una infraestructura de TI o en cual-
quier aspecto de un servicio de TI. Es un documento en el que se introducen la
naturaleza, los detalles, la justificación y la autorización del cambio propuesto.
La RFC va actualizándose a lo largo de la vida del cambio.
Revisión postimplementación (PIR, Post Implementation Review). Revisión
liderada por el gestor del cambio. Esta actividad, previa al cierre del cambio,
tiene como objetivo confirmar que el cambio ha cubierto sus objetivos, que los
clientes están satisfechos con los resultados y que no se han producido efectos
colaterales.

Las interacciones y funcionalidades de la gestión del cambio se resumen sucinta-
mente en la figura 9.2.5.
El proceso se desencadena con la recepción de una petición de cambio (RFC) o
con la necesidad de realizar un cambio de emergencia. La petición de cambio nor-
mal sigue el ciclo de vida del cambio, mientras que la necesidad de cambio de emer-
gencia sigue el procedimiento rápido de aprobación, convocándose, si fuera nece-
sario, el CAB de emergencia. El proceso utiliza otras entradas para el soporte de su
actividad: la información existente en la CMDB, la lista vigente de cambios planifi-
cados (FSC), la base de datos de cambios con el registro de todos los cambios, el
plan del proyecto (en el caso de que el cambio se haya construido bajo un pro-
yecto), el plan de pruebas definido en el proyecto y el análisis del impacto del cam-
bio realizado por el proyecto o promotor del cambio.
La primera actividad del proceso es precisamente la encaminada a planificar e
implementar la propia gestión del cambio. Una vez implementado, empieza a eje-
cutarse el ciclo de vida de cada cambio, que se inicia con la recepción de la RFC y
concluye con su cierre. El responsable del proceso convoca y lidera las sesiones del
comité de cambios (CAB), manteniéndose la lista con todos los cambios planifi-
cados (FSC). Se actúa ante la necesidad de cambios de emergencia para que se
implementen lo más rápido posible, supervisándose y monitorizándose estadísti-
camente todos los cambios preautorizados. Se realiza la supervisión de todo el
Desencadenantes 3 Planificación e implementación de Salidas principales:

del proceso: la gestión del cambio. Ü Cambio implementado
Ü RFC de diferentes 3 Gestionar el ciclo de vida • Comunicación usuario.
fuentes. completo de los cambios, desde
• Actualización CMDB
Ü Necesidad cambio de el RFC hasta su cierre:
y DSL.
emergencia. Registrar, evaluar el impacto
• Actualización BD de
del cambio (PSA), planificar,
Entradas de soporte: cambios.
aprobar, seguir, comprobar
Ü CMDB. (PIR) y cierre. Salidas secundarias:
Ü Lista de cambios 3 Convocar y liderar el CAB. Ü RFC cerradas.
programados (FSC) Aprobar los cambios.
Ü Lista de cambios
anterior. 3 Mantener la lista de programados (FSC).
Ü BD de cambios. cambios programados (FSC).
Ü Informe de
Ü Plan del proyecto. 3 Actuación en cambios de disponibilidad
emergencia. prevista (PSA).
Ü Plan de pruebas.
3 Monitorización de los cambios Ü CMBD actualizada.
Ü Análisis del impacto del
preautorizados.
cambio. Ü DSL actualizada
3 Supervisión del funcionamiento
Ü Propuesta de actividades
del proceso. Mejora del proceso.
para la mejora del
3 Informes y análisis sobre las proceso.
acciones de gestión del cambio.
3 Estar al día y conocer los
servicios: funcionalidad e
infraestructura.
Figura 9.2.5. Entradas, actividades y salidas del proceso de gestión del cambio
funcionamiento del proceso. Se emiten informes y análisis sobre las acciones de

gestión del cambio. El gestor del cambio debe estar permanentemente informado
y al día de los servicios, la funcionalidad ofrecida y la infraestructura que utilizan,
ya que es la última autoridad responsable de la aprobación de los cambios.
Como es lógico, la salida principal del proceso es el cambio implementado, con
calidad y dentro del plazo acordado. La implementación lleva asociada que se ha
mantenido la comunicación con el usuario, se ha actualizado la CMDB y la DSL,
así como, la base de datos de cambios. Las salidas secundarias del proceso son: las
RFC cerradas, la lista de cambios planificados (FSC) actualizada, el informe de dis-
ponibilidad prevista (PSA), la CMDB y DSL actualizadas, y las propuestas de
mejora del proceso.
De una forma específica, las Normas ISO/IEC 20000 establecen unas directrices
concretas que el proceso de gestión del cambio debe cumplir y que se deben tener
en cuenta en la planificación, definición, implantación y operación habitual del pro-
ceso.
UNE-ISO/IEC 20000-1
Los cambios en los servicios y la infraestructura deben tener un ámbito claramente

definido y documentado.
Todas las peticiones de cambio se deben registrar y clasificar, por ejemplo en urgen-
tes, de emergencia, importantes, menores. Se debe evaluar el riesgo, el impacto y
los beneficios para el negocio de las peticiones de cambio.
El proceso de gestión del cambio debe incluir la forma en que puede darse marcha
atrás o corregir cada cambio si no se realiza con éxito.
Los cambios se deben aprobar y tras ello deben ser comprobados, y deben ser
implementados de una forma controlada.
Las fechas planificadas para la implementación de los cambios se deben utilizar
como base para la planificación de cambios y entregas. Se debe mantener y comu-
nicar a las partes correspondientes la planificación que contenga los detalles de
todos los cambios aprobados para su implementación y las fechas propuestas.
UNE-ISO/IEC 20000-2
Los procesos y procedimientos de ges- cambios es supervisado y mejo-

tión de cambio deberían garantizar que: rado;
a) los cambios tienen claramente defi- f) puede demostrarse cómo un cam-
nido y documentado su alcance; bio es:
b) sólo son aprobados los cambios 1) generado, registrado y clasifi-
que proporcionan beneficios al cado (con las referencias a
negocio, por ejemplo: comerciales, los documentos que dieron
legales, regulatorios o estatutarios; origen al cambio);
c) los cambios son planificados en 2) evaluado en relación al im-
base a la prioridad y al riesgo; pacto, la urgencia, el coste,
los beneficios y el riesgo del
d) los cambios a las configuraciones cambio en el servicio, en los
pueden ser verificados durante la clientes y en los planes de
implementación del cambio; despliegue;
e) cuando sea requerido, el plazo 3) revertido o remediado, si no
para la implementación de los tuvo éxito;
4) documentado, por ejemplo, 9) planificado, supervisado e in-

la solicitud de cambio está cluido en un informe;
asociada a los elementos de 10) asociado a incidentes, proble-
configuración afectados, a mas, otro cambio y a los regis-
la versión actualizada de la tros de elementos de configu-
implementación y a los planes ración, cuando sea apropiado.
de despliegue;
5) aprobado o rechazado por El estado de los cambios y las fechas de
una autoridad de cambios, implementación planificadas se debe-
dependiendo de su tipo, rían usar como base para la planifica-
tamaño o riesgo; ción del cambio y del despliegue.
6) implementado por el respon- La información de planificación debería
sable designado dentro de estar disponible para las personas afec-
los grupos responsables de los tadas por el cambio.
componentes a ser cambia-
Cuando se pueda ocasionar una per-
dos;
dida del servicio durante el horario nor-
7) probado, verificado y entre- mal del servicio, las personas afectadas
gado; deberían acordar el cambio antes de su
8) cerrado y revisado; implementación.
Para garantizar una correcta gestión de los servicios, los procesos y procedimientos
de gestión de cambio deberán garantizar que los cambios tengan su alcance clara-
mente definido y documentado. En coordinación con la estrategia y la gestión del
porfolio de proyectos, la gestión del cambio también vela por que sólo sean apro-
bados los cambios que proporcionan beneficios al negocio, por ejemplo, comercia-
les, legales, regulatorios o estatutarios.
En la planificación del proceso, es recomendable definir y establecer los motivos
por los que se realizarán cambios, y quienes serán los promotores de estos cambios,
acotándose claramente los actores y la forma en la que se van a producir las entra-
das del proceso.
En la implementación de una adecuada política de gestión del cambio en la
organización se deben superar algunos aspectos culturales críticos como los
siguientes:
• Que los diferentes departamentos acepten la autoridad de la gestión del
cambio.
• Que se sigan con rigor los procedimientos establecidos y, en particular, que
se actualice correctamente en la CMDB la información sobre los elementos
del servicio cambiados.
• Que los encargados de la gestión del cambio conozcan a fondo las activida-
des, servicios, necesidades y estructura de la organización capacitándoles
para desarrollar correctamente su actividad.
• Que los gestores del cambio dispongan de las herramientas adecuadas de soft-
ware para monitorizar y documentar adecuadamente el proceso.
• Y por supuesto, el compromiso suficiente de la dirección por implementar
rigurosamente los procesos asociados.
En este aspecto, es recomendable que en las fases iniciales de la implementación del

proceso se preste atención en conseguir el consenso y la implicación de todos los
involucrados, ya que promotores, gestores, supervisores, personal técnico de des-
pliegues y titulares de los elementos de configuración de la CMDB, se van a ver
envueltos en un proceso que seguramente les va a cambiar su forma de trabajar.
También es importante que la figura del responsable del proceso tenga la autoridad
suficientemente reconocida en la organización para llevarlo a cabo, contando con la
participación de todos y el apoyo de la dirección.
Es recomendable implantar de forma conjunta los dos procesos de control: la ges-
tión del cambio y la gestión de la configuración. Así, con el primero garantizamos
el control de todo cambio en los servicios, mientras que el segundo mantiene la
fidelidad de toda la información relacionada con los servicios. Implantando ambos
procesos se consigue que:
• Los CI afectados por los cambios se hallen siempre registrados en la CDMB.
• Los CI registrados en la CMDB estén sujetos al control del proceso de ges-
tión del cambio.
Debe existir también un procedimiento, medio de publicación o notificación de

cambios, en función de su relevancia que incluya: los medios de comunicación, los
actores a comunicar, las confirmaciones de recepción de notificación o informacio-
nes (si se precisan), al nivel de autoridad definido por el proceso, que evidencie que
todas las partes implicadas (y especialmente el cliente) están debidamente informa-
das de la activación de un cambio.
El tratamiento de las descargas automáticas a través de Internet, que son conti-
nuas en el ámbito de los ordenadores personales, es un tema que se debe analizar
de forma detallada en la organización y establecer las políticas de gestión adecua-
das. Estas descargas se despliegan autónomamente en el entorno productivo y
cambian la configuración del puesto de trabajo. De una forma automática tam-
bién se saltan varios procesos esenciales: la gestión del cambio, de la entrega y de
la configuración.
Ciclo de vida completo de un cambio

La misión principal del proceso es poner orden y control, estableciendo unas etapas
y aprobaciones que deben seguir los cambios habituales. En el gráfico de la figura
9.2.6 se muestra un esquema del ciclo de vida de un cambio.
Figura 9.2.6. Ciclo de vida completo de un cambio grande (macro o mayor)
El ciclo de vida de un cambio se resume en las siguientes tareas:

• Registrar, evaluar y aceptar o rechazar las solicitudes de cambio (RFC) reci-
bidas. Se establece su categoría y prioridad, y se analiza el informe de dispo-
nibilidad prevista (PSA) y el plan de pruebas del cambio.
• Aprobar la construcción del cambio. Para ello, se convocan reuniones del
comité de cambios (CAB). En el caso que durante la construcción del cambio
se modificaran sustancialmente los acuerdos establecidos, el cambio deberá

volver a ser tratado en el CAB.
• Elaboración y mantenimiento actualizado de la planificación unificada de
todos los cambios en curso (FSC o lista de cambios planificados).
• Coordinar la construcción e implementación del cambio. El proceso de ges-
tión del cambio es el responsable también de coordinar toda la actividad de
construcción de los cambios. En cambios grandes o en la creación de servi-
cios, que se estructuran en forma de proyecto, la coordinación la realiza el
jefe de proyecto actuando como parte del proceso de gestión del cambio para
esta actividad. En cambios menos complejos, en que no existe la función de
jefe de proyecto, es el personal asignado al proceso quien deberá realizar la
función de coordinación.
• Aprobar la implantación del cambio. Una vez construido el cambio y acep-
tada la entrega por el jefe de proyecto, se solicita a este proceso que se res-
ponsabilice de los aspectos necesarios para coordinar la implantación del
cambio.
• Controlar la etapa implantación, que comprende la integración, pruebas y
despliegue del cambio. Es la responsabilidad única del proceso de cambio
y todas las actividades restantes, desde la integración y pruebas, hasta el paso
final al entorno de producción. Aunque el proceso de cambio delega (pero
supervisa) los trabajos organizativos y técnicos a realizar para implantarlo al
proceso de gestión de la entrega que a su vez utiliza a las áreas técnicas.
• Aprobar el paso a producción del cambio. Finalizada con éxito la etapa de
integración y pruebas por parte de gestión de la entrega, el gestor del cam-
bio autoriza el paso al entorno productivo en vivo. También es el proceso de
entrega el que realiza esta labor. En esta etapa es importante la estrecha coor-
dinación de todos los cambios a pasar al entorno productivo para minimizar
el impacto en el negocio con las paradas, así como mantener informados a
los clientes, usuarios y al centro de atención al usuario.
• Evaluar los resultados del cambio mediante la revisión postimplantación
(PIR) para confirmar que se han cubierto sus objetivos definidos, que los
clientes están satisfechos con los resultados, y que no se han producido efec-
tos colaterales. Posteriormente se procede al cierre del cambio y a la comuni-
cación del mismo al cliente.
• Gestionar la mejora del proceso. Como todos los procesos, se debe tener en
cuenta el proceso de mejora continua: monitorizar, informar, dirigir la cali-
dad y cumplimiento de lo establecido para el proceso de cambio, comunicar
resultados y establecer las mejoras que se deben realizar (que se incorporarán

en el plan unificado de mejora de la gestión del servicio).
En el caso de cambios normales o menores, este ciclo de vida puede resultar pesado
y poco eficiente, por lo que se debería aligerar eliminando las etapas que no apor-
ten valor.
La solicitud de cambio (RFC, Request For Change)

La solicitud de cambio es el desencadenante principal de la actividad del proceso
de gestión del cambio, y la persona que la realiza es el promotor del cambio.
En los cambios de emergencia, es posible que la RFC se tenga que formalizar a
posteriori, cuando se haya salido de la crisis.
El origen de una RFC puede ser muy distinto, por ejemplo:
• La creación de nuevos servicios o evolución de los existentes. El desarrollo
de nuevos servicios normalmente requiere cambios en las aplicaciones y en la
infraestructura de TI. En este caso es importante coordinar todo el proceso
con las gestiones de capacidad, disponibilidad y nivel de servicio para asegu-
rar que estos cambios cumplen las expectativas previstas y no deterioran la
calidad de los otros servicios prestados.
• La resolución de incidentes. Gestión del incidente, en su actividad de restau-
rar el funcionamiento normal del servicio tan rápido como sea posible,
puede requerir cambios en la infraestructura de TI. En estos casos, la RFC
debe contener la información del incidente relacionado.
• La resolución de problemas. Gestión del problema se encarga de proponer
soluciones a errores conocidos. En la mayoría de los casos esta solución aca-
rrea un cambio en la infraestructura de TI. En este caso, la RFC debe ser
registrada con información del error conocido asociado para que, posterior-
mente, pueda ser evaluada correctamente la pertinencia del cambio.
• La estrategia empresarial. La dirección puede decidir una nueva dirección
estratégica que puede afectar, por ejemplo, a los niveles de servicio ofrecidos o
a la implantación de un nuevo servicio, etc., y que por regla general, requieren
cambios de hardware, software y/o procedimientos.
• Las actualizaciones de software de terceros. Los proveedores pueden dejar de
soportar versiones anteriores de paquetes de software o introducir nuevas ver-
siones con grandes mejoras que recomienden la actualización.
• El cumplimiento de un imperativo legal. Un cambio de legislación (como

por ejemplo, la LOPD (Ley Orgánica de Protección de Datos de carácter
personal, en España) puede exigir cambios en la infraestructura de TI.
• Otro origen. En principio, cualquier empleado, cliente o proveedor puede
sugerir mejoras en los servicios que pueden requerir cambios en la infraes-
tructura.
Se debe definir una estructura y formato para la solicitud de cambio. Según sea el
tamaño del cambio, la información a incorporar a la RFC será más amplia cuanta
mayor complejidad tenga el cambio para tener un mejor control sobre él. Así en
cambios grandes, el jefe de proyecto añadirá a la RFC los siguientes documentos:
• Una planificación detallada.
• Un estudio de rentabilidad o business case.
• Un informe de disponibilidad prevista (PSA).
• Un plan de pruebas del cambio.
En la figura 9.2.7 se muestra el contenido típico de una RFC.

Es importante resaltar que los tipos de cambio pueden ser de muy diversa natura-
leza y complejidad, por lo que la RFC es un documento vivo y que dependiendo
del marco temporal, puede ir evolucionando y completándose con información
clave que se vaya obteniendo a lo largo del proceso.
Registro de la RFC
En todos los cambios, la solicitud de cambio es recibida por el proceso de cambio
y desencadena las actividades del ciclo de vida del cambio. La primera de ellas, es el
registro de la RFC que, normalmente, lo realizará el propio promotor del cambio
en la herramienta de gestión del proceso. En el registro se introduce la información
inicial de la RFC.
Aceptación de la RFC
Tras el registro de la RFC se debe evaluar preliminarmente su pertinencia. Una
RFC puede ser rechazada si se considera que el cambio no está justificado o se
puede solicitar su modificación si se considera que algunos aspectos de la misma
son susceptibles de mejora o mayor definición. En este caso, la RFC debe ser
Solicitud de cambio (RFC)
Identificador de RFC.
Fecha de solicitud.
Intervinientes en el cambio.
Responsable del cambio/Solicitante del cambio - patrocinador del cambio.
Descripción del cambio.
Agenda del cambio.
Fecha de implantación y fechas intermedias relevantes.
Metas y objetivos.
¿Cuál es el estado actual?, ¿Por qué es necesario el cambio? ¿Cuál es el resultado
deseado del cambio? ¿Cuáles son las consecuencias si el cambio es rechazado o
pospuesto?, etc.
Información económica.
Información de costes y presupuesto.
Prioridad del cambio.
Planificación del cambio.
Plan de proyecto de creación del servicio.
Estimación de recursos.
Tiempos/Utilización de recursos; por ejemplo, los tiempos necesarios para
probar/implementar el cambio.
Impacto del cambio.
Proveer información acerca del impacto del cambio (por ejemplo, en la empresa, el
departamento, el sistema). Esta descripción debe marcar la importancia del cambio
y el riesgo asociado.
Documentación.
Información relevante relacionada con las modificaciones provocadas por el cambio
solicitado.
Consideraciones clave y riesgos asociados.
Circunstancias bajo las que no se recomienda implementar el cambio. Requisitos
previos a la implementación del cambio.
Riesgos asociados al cambio. Descripción y aprobación.
Aprobaciones.
Aprobación o denegación de la solicitud de cambio y fecha.
Responsables y firma de los integrantes del CAB intervinientes.
Observaciones/comentarios emitidos en el proceso.
Revisión post implantación.
Resultado del cambio.
Fecha de la revisión.
Responsables y firma de los encargados de la revisión.
Observaciones/comentarios emitidos en el proceso.
Figura 9.2.7. Formato ejemplo de una solicitud de cambio

devuelta al departamento o persona que la solicitó, para que se puedan realizar nue-
vas alegaciones o para que pueda ser modificada.
La aceptación de la petición de cambio no implica su posterior aprobación por el
CAB, es sólo indicación de que se ha encontrado justificado su procesamiento.
Clasificación del cambio

Tras su aceptación, la RFC se debe clasificar para asignarla una categoría y una
prioridad con el fin de gestionarla de la forma más eficaz posible.
La categoría determina la dificultad, riesgo e impacto del cambio y será el paráme-
tro relevante para determinar la asignación de recursos necesarios, los plazos pre-
vistos y el nivel de autorización requerido para la implementación del cambio. En
la figura 9.2.8 se describen las categorías habituales.
Categoría
Descripción
del cambio
Un impacto de gran importancia, y/o una cantidad muy grande de

Macro recursos necesarios, o un impacto probable sobre otras partes de la
organización.
Mayor Impacto significativo y/o bastantes recursos necesarios.
Menor Sólo un impacto de poca importancia, y pocos recursos necesarios.
Un cambio recurrente, bien conocido, para el que existe un procedi-

Preautorizado
miento predefinido a seguir, con un riesgo relativamente bajo.
Figura 9.2.8. Ejemplo de tipos de categorías de un cambio
La categoría de un cambio concreto puede ir evolucionando en el tiempo según la

organización vaya adquiriendo experiencia en la ejecución de ese cambio en parti-
cular. Por ejemplo, un cambio menor que se ha implantado en numerosas ocasio-
nes y para el que se ha desarrollado un procedimiento de implantación puede ter-
minar convirtiéndose en un cambio estándar (preautorizado).
La prioridad es el valor dado al cambio (RFC) para indicar su importancia rela-
tiva, al objeto de asegurar la adecuada asignación de recursos y para determinar el
intervalo de tiempo en el que se requiere una acción. La prioridad dependerá de:
• El impacto. Medida del efecto sobre el negocio que el tiene cambio actual-
mente o podría tener potencialmente. Se relaciona con el grado de incumpli-
miento del SLA. Se puede valorar en función de la criticidad para el negocio
del/los servicio/s afectado/s, el número de usuarios afectados y su importan-
cia relativa en la organización.
• La urgencia. Medida de la criticidad para la atención de un cambio, en fun-
ción de los tiempos límites que fueron pactados con el negocio. Puede iden-
tificarse con el tiempo disponible para su tratamiento antes de que se llegue
al incumplimiento del SLA. Se puede establecer mediante la estimación del
tiempo necesario para la resolución, tomando como referencia los tiempos
de respuesta establecidos en el SLA.
En cualquier caso, los criterios para definir el impacto y la urgencia deberían esta-
blecerse en coordinación con los responsables del negocio y formalizarse en el SLA.
En la figura 9.2.9 se presentan los tipos de prioridad más habituales y su corres-
pondencia con el procedimiento aplicable.
Tiempo de
Prioridad Descripción Procedimiento
atención
Se necesita una acción inmediata. Puede ser necesa-

rio convocar reuniones urgentes del Comité de cam-
Crítica bios (Comité de Cambios de Emergencia). Puede ser minutos Emergencia
necesario asignar recursos inmediatamente para desa-
rrollar tales cambios autorizados.
Será asignada la más alta prioridad en cuanto a

Alta horas Normal
recursos de desarrollo, pruebas e implementación.
Será asignada una prioridad media en cuanto a la

Media días Normal
asignación de recursos.
El cambio es justificable y necesario, pero puede

esperar hasta la próxima entrega o actualización
Baja días Normal
programada. Serán asignados unos recursos de
acuerdo con esto.
Figura 9.2.9. Ejemplo de tipificación de prioridades de un cambio
La clasificación permite la ejecución rápida del cambio, las evaluaciones del

impacto, la estimación de la capacidad de las colas de trabajo y su posterior evalua-
ción del rendimiento y la gestión de la calidad en los resultados.
Reuniones del comité de cambios (CAB, Change Advisory

Board)
Según se haya establecido en el sistema de gestión de TI (SGSTI) y en la implanta-
ción del proceso, el comité de cambios debe reunirse periódicamente para analizar
y eventualmente aprobar las solicitudes de cambio, y revisar la lista de cambios pla-
nificados (FSC). El papel del CAB es únicamente de asesor al gestor del cambio,
por lo cual la responsabilidad y la decisión final es siempre del gestor del cambio.
Las reuniones del comité de cambios las convoca y lidera el gestor del cambio. El
CAB tiene miembros permanentes (gestores de los procesos: nivel de servicio, dis-
ponibilidad, capacidad, problema, entrega, etc.) y miembros invitados relacionados
con los cambios a tratar (promotores de los cambios, gestor relaciones con el nego-
cio, área cliente, etc.), tal y como se muestra en la figura 9.2.10.
Una agenda tipo del CAB:

• RFC para que CAB la evalúe.
Lo convoca y lo lidera: • Revisiones de los cambios realizados
y en curso. Cambios fallidos.
el gestor del cambio
• Evolución del proceso de gestión del
cambio.
• Logros y éxitos.
Miembros permanentes:
• Gestión de nivel de servicio.
• Gestión de la disponibilidad.
• Gestión de la capacidad. Miembros invitados:
• Gestión del problema. • Promotores de los cambios.
• Gestión entrega. • Gestor relaciones con el negocio.
• Gestión centro servicio al usuario. Comité de cambios • Áreas cliente.
• Áreas técnicas. (CAB) • Especialistas.
Figura 9.2.10. Composición del comité de cambios
La frecuencia y el tipo de reuniones del comité de cambios (presénciales, telefóni-

cas, etc.) se deben determinar en función del volumen y tipo de cambios que se
vayan a realizar. Estas reuniones representan un consumo de tiempo importante
para sus miembros. Por tanto, se deben establecer medidas para agilizar las reunio-
nes del CAB, como por ejemplo, facilitar el acceso a la documentación a tratar
antes de la reunión, control estricto del tiempo de la reunión, permitir flexibilidad
para enviar a un representante si el titular no puede asistir, facilitar que algunos
miembros asistan de forma remota (especialmente los invitados que sólo deban
participar en un cambio), realizar algunas reuniones por medios electrónicos
no presenciales. En cualquier caso, se recomienda tener periódicamente una reu-

nión presencial del CAB con los miembros permanentes.
El comité de cambios debe incluir representación de todas las capas tecnológicas
dentro de TI, además de representación de los principales clientes de TI.
En cualquier caso, la aprobación de los cambios es responsabilidad única del gestor
del cambio, ya que es el responsable de autorizar o denegar un cambio. De ahí la
importancia de seleccionar un profesional adecuado para este rol, ya que debe
conocer con detalle la estructura de los servicios y su impacto en el negocio. Aun-
que parezca poco democrática, la función del CAB es únicamente asesora.
Durante el ciclo de vida del cambio, y según lo establezca cada organización en su
SGSTI, el cambio podrá estar sometido a varias aprobaciones. Así, en grandes
cambios (macro y mayores), se podría pasar por:
• La aprobación de la construcción del cambio, se debería consultar al CAB.
• La aprobación de la implementación del cambio, para iniciar la integración,
pruebas y despliegue a realizar por el proceso de gestión de la entrega, que
realiza también el CAB.
• La aprobación del paso a producción del cambio tomada por el gestor del
cambio, se debería informar al CAB.
• La revisión postimplementación previa al cierre.
Para la aprobación de la construcción del cambio el gestor del cambio debe eva-
luarlo minuciosamente, especialmente los grandes (de categoría macro y mayor)
contemplando:
• Cuáles son los beneficios esperados del cambio propuesto. Revisión del caso
de negocio (business case) presentado por el promotor del cambio.
• Justificación de esos beneficios frente a los costes asociados al proceso de
cambio.
• Cuáles son los riesgos asociados. Revisión del informe de disponibilidad pre-
vista (PSA).
• Si se dispone de los recursos necesarios para llevar a cabo el cambio, en forma
y plazo, con garantías de éxito.
• Prioridad asignada: urgencia, conocer si puede demorarse el cambio e
impacto, cuál será el impacto general sobre la infraestructura y la calidad de
los servicios de TI.
• ¿Puede el cambio afectar los niveles establecidos de seguridad de TI?
En el caso de cambios que tengan un alto impacto debe también consultarse a la

dirección (CIO), pues pueden entrar en consideración aspectos de carácter estraté-
gico y de política general de la organización.
Una vez aprobada la implementación del cambio (en caso contrario se seguiría el
proceso para no aceptación), la gestión de la entrega debe evaluar si se ha de imple-
mentar aisladamente o integrado en un “paquete de cambios”, que formalmente
equivaldrían a un solo cambio. Esto tiene algunas ventajas:
• Se optimizan los recursos necesarios.
• Se evitan posibles incompatibilidades entre diferentes cambios.
• Sólo se necesita un plan de marcha atrás.
• Se simplifica el proceso de actualización de la CMDB, la DSL y la revisión
postimplementación.
Mantenimiento de la lista de cambios planificados

(FSC, Forward Schedule of Change)
La planificación es esencial para una buena gestión de los cambios tanto individuales,
como de todo el proceso en su conjunto. Cada cambio debe tener asociada una pla-
nificación, que en el caso de los menores puede bastar con una simple tabla de
fechas y duraciones incorporada en la RFC. Pero en cambios macro o mayores,
deben llevar una planificación detallada de todas las etapas del mismo.
Con todas las planificaciones individuales, gestión del cambio mantiene actualiza-
das las listas unificadas de cambios en curso o lista de cambios planificados (FSC),
que sirve para que toda la organización del proveedor de TI conozca la actividad y
planifique sus recursos.
La FSC debería incluir detalles de todos los cambios autorizados, incluyendo los
planes claros a corto plazo y a más largo plazo. También deberían incluirse los gran-
des planes de transformación ligados a la estrategia de evolución prevista para los
próximos dos años. La FSC debería distribuirse entre las áreas cliente, los desarro-
lladores de aplicaciones, el personal de soporte, incluido el centro de servicio al
usuario, y cualquier otra parte interesada.
Construcción del cambio

La construcción del cambio (aplicación e infraestructura) no la realiza el proceso de
gestión del cambio. Normalmente la realiza el equipo de desarrollo de aplicaciones
y/o la gestión de infraestructuras de TI. Pero el proceso de gestión del cambio debe
realizar una supervisión de esta actividad.
En la fase de construcción del cambio se deberá supervisar el proyecto para asegu-
rar que:
• Tanto el software desarrollado como el hardware adquirido se ajustan a las
especificaciones predeterminadas.
• Se cumplen los calendarios previstos y la asignación de recursos es la adecuada.
• El entorno de pruebas es realista y simula adecuadamente el entorno de pro-
ducción.
• Los planes de marcha atrás permitirán la rápida recuperación de la última
configuración estable.
• Si es posible, debe permitirse el acceso restringido de usuarios al entorno de
pruebas para que realicen una valoración preliminar de los nuevos sistemas
en lo que respecta a su funcionalidad, usabilidad y accesibilidad.
Implementación de un cambio
La etapa de implementación corresponde a la integración del cambio en la infraes-
tructura, a las pruebas finales y al paso al entorno productivo.
Aunque la gestión del cambio no es la encargada directa de implementar el cambio,
algo de lo que se encarga habitualmente la gestión de la entrega (con recursos de
infraestructuras y del propio proyecto) o directamente los equipos técnicos, sí es la
encargada de supervisar y coordinar todo el proceso. Mientras que en ISO/IEC
20000 y en ITIL v2 es el proceso de gestión de la entrega (release management), en
ITIL v3 la implementación de cambio se realiza bajo el proceso denominado “ges-
tión de versiones y despliegues” (release and deployment management).
Evaluación de resultados, revisión postimplantación (PIR)

y cierre del cambio
Cuando todos los trabajos de implantación y despliegue se dan por finalizados por
el proceso de gestión de la entrega, se procede a la evaluación de los resultados del
cambio.
Antes de proceder al cierre del cambio es necesario realizar una evaluación que permita
valorar realmente si se han cubierto los objetivos establecidos y cuál ha sido el impacto
del mismo en la calidad del servicio y en la productividad de la organización. Para ello,

se procede a la revisión postimplementación (PIR, Post Implementation Review).
UNE-ISO/IEC 20000-1
Se debe revisar el éxito de todos los cambios y, en caso contrario, se deben decidir y
llevarse a cabo acciones correctivas tras la implementación.
UNE-ISO/IEC 20000-2
Todos los cambios se deberían revisar c) no ha habido efectos colaterales

en relación a su éxito o fallo después de inesperados.
la implementación y cualquier mejora
Toda no conformidad se debería regis-
debería ser registrada. Se debería reali-
trar y tomarse las acciones pertinentes.
zar una revisión después de la imple-
mentación en los cambios principales Cualquier debilidad o deficiencia identi-
para comprobar que: ficada en la revisión del proceso de ges-
a) el cambio cumple sus objetivos; tión del cambio, debería alimentar los
planes de mejora del servicio.
b) los clientes están satisfechos con
los resultados;
La gestión del cambio se encarga de realizar su propia revisión postimplementa-

ción consultando a las partes implicadas, para asegurar que los cambios realmente
han sido satisfactorios. Los aspectos fundamentales que debe tener en cuenta el
PIR son los siguientes:
• ¿Se cumplieron los objetivos previstos?
• En qué medida se apartó el proceso de las previsiones realizadas por la ges-
tión del cambio.
• ¿Provocó el cambio problemas o interrupciones del servicio imprevistas?
• ¿Cuál ha sido la percepción de los usuarios respecto al cambio?
• ¿Se pusieron en marcha los planes de marcha atrás en alguna fase del pro-
ceso? y ¿por qué?
Si la evaluación final determina que el proceso y los resultados han sido satisfacto-
rios, se procederá al cierre de la RFC.
Marcha atrás de un cambio

Los servicios de TI son muy susceptibles a los cambios en su configuración, debido
a las sofisticadas interrelaciones entre todos los elementos involucrados. Un cam-
bio aparentemente menor, puede desencadenar una reacción en cadena con resulta-
dos catastróficos. Es imprescindible, como mínimo, disponer siempre de planes de
marcha atrás (back out) que permitan la recuperación de la última configuración
estable antes del cambio.
La gestión de la entrega es responsable de definir las políticas de implantación y des-
pliegue de cambios, y también de qué forma se han de realizar los planes de marcha
atrás. La gestión del cambio debe garantizar que todos los cambios son aprobados
con la suficiente documentación, infraestructura y recursos para que el cambio se eje-
cute con éxito. En el caso en que los resultados sean desfavorables, se tendrían que
ejecutar los planes de marcha atrás, dentro de la ventana horaria más favorable al
cumplimiento del plan de disponibilidad y dentro de los límites concertados.
Una marcha atrás sin un procedimiento especifico o con un cronograma abierto es
muy desaconsejable.
Una vez cerrado el cambio, no se debe realizar una acción de marcha atrás, por el
impacto en otros servicios y en la información que manejan. Muy posiblemente,
los datos hayan cambiado y se pierda información del negocio. En este caso se
deberá realizar una acción correctiva, y posteriormente analizar que falló en la acti-
vidad PIR.
La opinión de los usuarios se debe tener en cuenta, y el cambio debe revisarse en el
caso en el que se encuentren objeciones justificadas (debe tenerse en cuenta tam-
bién la resistencia habitual al cambio).
Cambios de emergencia
Cualquier interrupción del servicio de alto impacto, ya sea por el número de usuarios
afectados o porque se han visto involucrados sistemas o servicios críticos para la orga-
nización, debe encontrar una respuesta inmediata adecuada. Es frecuente que la solu-
ción al incidente requiera un cambio urgente, pero hasta las urgencias y las situacio-
nes de crisis, deben estar reguladas mediante un procedimiento de emergencia.
El procedimiento que se debe seguir en estos casos de crisis debe estar debidamente
previsto. Como el objetivo prioritario en estas situaciones críticas es restaurar el
servicio, es a menudo frecuente que los procesos asociados sigan un orden inverso
al usual, realizándose a posteriori tanto en los registros en la CMDB, como en la
documentación asociada al cambio.
Sin embargo, es esencial que al cierre del cambio de emergencia se disponga de la

misma información de la que dispondríamos tras un cambio normal.
UNE-ISO/IEC 20000-1
Deben existir políticas y procedimientos para controlar la autorización e implemen-

tación de cambios de emergencia.
UNE-ISO/IEC 20000-2
En ocasiones se requiere la realización cambio, el cambio debería cumplir estos

de cambios de emergencia, y cuando requisitos tan pronto como sea posible.
sea posible, se debería seguir el proceso Los cambios de emergencia se deberían
de cambio, aunque algunos detalles se justificar por quien los implementa y
documenten a posteriori. Cuando el pro- deberían ser revisados después del
ceso de emergencia se salte algunos cambio para verificar que era una ver-
requisitos del proceso de gestión del dadera emergencia.
Un cambio de emergencia requiere, como su nombre indica, una actuación inme-

diata. Estos cambios provocan trastornos en el ritmo de trabajo de toda la organi-
zación, desplazamientos de otros cambios y replanificaciones encadenadas, etc. Por
ello, es extremadamente importante reducir el volumen de los cambios de emer-
gencia. Habitualmente muchos de los cambios de emergencia surgen como resul-
tado de una planificación deficiente o de una organización trastabillada. Así, una
cuidada planificación y programación de los cambios y una buena gestión de los
plazos que necesita el negocio son las palancas de reducción de este factor.
En un cambio de emergencia, normalmente el CAB no se reúne físicamente, sino
que están identificados los participantes (normalmente de alto nivel) que asesoran
si se debería llevar a cabo o no. Este subgrupo del comité de cambios, se le suele
denominar CAB de emergencia. Pero como siempre, convocarlo y la aprobación
es responsabilidad del gestor del cambio.
Informes, análisis y acciones de mejora

En este caso, la norma nos recuerda la necesidad de medir, analizar y registrar las
conclusiones. Indica que las acciones de mejora del proceso se incorporen en el
plan general de mejora de la gestión del servicio.
UNE-ISO/IEC 20000-1
Los registros de cambios se deben analizar regularmente para detectar incrementos

en el volumen de cambios, tipos recurrentes frecuentemente, tenencias emergentes y
cualquier otra información relevante. Los resultados y conclusiones obtenidos a par-
tir del análisis de los cambios se deben registrar.
Las acciones de mejora identificadas para la gestión del cambio se deben registrar y
debe proporcionar información de entrada al plan de mejora del servicio.
UNE-ISO/IEC 20000-2
Los registros de los cambios se deberían información relevante. Los resultados y

analizar de forma periódica, para las conclusiones derivados del análisis
detectar incrementos en el nivel de cam- de los cambios se deberían registrar y
bios, frecuencia de los tipos recurrentes, actuar sobre ellos.
tendencias emergentes y cualquier otra
Es imprescindible elaborar informes que permitan conocer el rendimiento de la

gestión del cambio. Para que estos informes ofrezcan una información precisa y
que permita conocer la evolución a lo largo del tiempo del proceso y de su con-
tribución al éxito de los servicios de TI, es imprescindible elaborar indicadores o
métricas.

Las métricas se deben adaptar a las necesidades de control o de conocimiento que
tenga cada organización, aportando información sobre el funcionamiento interno
del proceso, cómo el proceso contribuye al éxito de los servicios de TI, o el valor
aportado por TI al negocio. Suelen cubrir aspectos tales como por ejemplo, los
siguientes:
• El volumen de RFC gestionados, el porcentaje de RFC aceptados y aprobados.
• El número de cambios realizados distinguiendo entre su prioridad y su cate-
goría.
• El tiempo medio de implementación del cambio dependiendo de su priori-
dad y su categoría (plazos de cambios).
• El número de cambios de emergencia realizados.
• El porcentaje de cambios con éxito en una primera instancia, en una segunda

instancia, etc.
• El número de operaciones de marchas atrás que se han tenido que realizar,
con una detallada explicación de las mismas.
• Los resultados de las evaluaciones postimplementación.
• El porcentaje de cambios cerrados sin incidencias posteriores.
• La cantidad de incidencias asociadas a cambios realizados.
• El número de reuniones realizadas por el CAB, con información estadística
asociada: número de asistentes, duración, número de cambios aprobados por
reunión, etc.
En el gráfico de la figura 9.2.11 se muestra una visión muy parecida a la anterior,

proveniente de un resumen de los indicadores más relevantes para este proceso
seleccionados por un grupo de trabajo de itSMF España.
de itSMF España
Roles participantes en la gestión del cambio

Como en el resto de los procesos, los roles intervinientes en la gestión del cambio
se estructuran en: los roles propios del proceso y los roles ajenos al proceso.
• El gestor del cambio (gestor del proceso o process manager), que es el respon-
sable del día a día de la actividad del proceso. En este caso, aprueba los cam-
bios, convoca y lidera el CAB, etc.
• Los promotores de los cambios son el personal de desarrollo, el de infraes-
tructuras y los técnicos o gestores de los procesos que realizan la solicitud del
cambio.
• Los administradores o el personal de soporte al proceso, ayudan al gestor
del cambio en el control de toda la actividad.
• Los jefes de los proyectos de desarrollo o de infraestructuras que controlan
todas las actividades asociadas a los cambios grandes.
• Los especialistas técnicos.
se representan en el gráfico de la figura 9.2.12.
Resumen
La necesidad de continua evolución de las tecnologías de la información requiere
una actividad constante de cambios en las infraestructuras y en los desarrollos para
permanecer actualizado y evitar que los servicios se queden obsoletos.
El proceso de gestión del cambio es clave para mantener la estabilidad de los
servicios, pues regula y controla toda actuación sobre ellos. El proceso necesita
Roles del proceso
Responsable de la
Promotores
Gestor
o solicitantes
del cambio
SGSTI de los cambios
Propietario del
modelo (SGSTI)
Comité de cambios
(CAB)
Administrador y
Especialistas soporte del proceso
técnicos del cambio
Figura 9.2.12. Roles del proceso de gestión del cambio
la información de la gestión de la configuración para determinar con precisión

el impacto del cambio, y por otra parte, garantiza que la información sobre los
servicios modificados permanece actualizada.
El proceso mantiene la fiabilidad de los servicios. Debe velar por que la actividad
evolutiva o correctiva de los mismos se realice con un consumo de recursos ade-
cuado, y debe contribuir a la agilidad evolutiva de la organización y al cumpli-
miento de los plazos de los cambios.
Los principales elementos que intervienen en el proceso son el responsable de cam-
bios, la solicitud de cambio (RFC), el comité de cambios (CAB), la lista de cambios
planificados (FSC), la clasificación de un cambio, los cambios de emergencia y la
revisión postimplementación (PIR).
El proceso controla y supervisa tanto la construcción del cambio como su imple-

mentación, pero no realiza este trabajo, que lo asumen los equipos técnicos
actuando bajo el proceso de la gestión de la entrega.
Beneficios
Los principales beneficios derivados de una correcta gestión del cambio son los
siguientes:
• Se reduce el número de incidentes y problemas potencialmente asociados a
todo cambio. Por lo tanto, se reduce el riesgo asociado a los cambios.
• Se reducen los plazos medios en la implantación de los cambios.
• La organización realiza los cambios con más eficiencia.
• Se reduce el impacto en el negocio debido a las paradas asociadas a los
cambios.
• Se puede retornar a configuraciones estables de manera sencilla y rápida en el
caso en el que el cambio tenga un efecto negativo.
• Se reduce el número de operaciones de marcha atrás necesarias.
• Los cambios son mejor aceptados y se evitan “tendencias inmovilistas”.
• Se evalúan los verdaderos costes asociados al cambio y, por tanto, es más sen-
cillo valorar el retorno real de la inversión.
• La CMDB y la DSL están correctamente actualizadas, algo imprescindible
para la correcta gestión del resto de los procesos de TI.
• Se reducen las actuaciones de emergencia y el trastorno que ocasionan en el
trabajo diario.
• Se desarrollan procedimientos de cambio estándar que permiten la rápida
actualización de sistemas no críticos.
• Cite tres ejemplos en su organización de cambios pre-autorizados, de
cambios mayores y de cambios de emergencia.
• Por limitación de recursos, debe escoger sólo 3 procesos para imple-
mentar en primer lugar. Si uno de ellos es gestión del cambio, ¿qué
otros dos procesos implementaría en su organización?
• ¿Qué aspectos de lo descrito en este apartado no se adaptan bien a
su organización? ¿Por qué?
1
10 Proceso de gestión
de la entrega
Capítulo 10
10.1. Gestión de la entrega


10. Procesos de gestión de la entrega 695
La mayor cantidad de fallos en los servicios viene generada por errores en los cam-
bios e implantaciones, tanto por defectos en su construcción como por errores en
las operaciones que conlleva la puesta en explotación. Pero las organizaciones de TI
deben mantener un ritmo constante de cambios y de creación de nuevos servicios
para responder de una forma ágil a las necesidades del negocio.
Realizar cambios en los servicios no es tarea sencilla, tanto por la cantidad de com-
ponentes hardware y software, como por el número de suministradores que entran
en escena para mantener los servicios de TI. Además, se requiere que los servicios
evolucionen sin interferir en la producción normal, manteniendo los niveles de servi-
cio acordados y garantizando los tiempos comprometidos, no sólo para las tareas
identificadas del despliegue, sino también para los plazos que marca el negocio
(time to market).
La importante misión de introducir cambios se realiza mediante dos procesos: la
gestión del cambio y la gestión de la entrega. Si la gestión del cambio pone control
y orden en todas las peticiones de cambio, bajo el concepto del proceso de entrega,
se agrupan las actividades operativas necesarias para que el cambio se ponga en el
entorno productivo, minimizando el riesgo de fallos y maximizando la eficiencia de
las tareas que se deben llevar a cabo.
Las Normas ISO/IEC 20000 dedican la mayor extensión de requisitos y recomen-
daciones a este proceso. El éxito en este proceso de entrega vendrá dado por la uti-
lización de unos procedimientos y tareas bien desarrollados y controlados, que per-
mitan una gestión correcta de los recursos puestos a disposición del proceso, y la
optimización y mejora del mismo.
Un proveedor de TI de tamaño medio suele realizar entre 70 y 100 cambios sema-
nales en sus servicios. Además de esto, cada servicio operativo suele tener dos o tres
grandes versiones al año. Para complicarlo aún más, muchos estos cambios se debe-
rán realizar fuera de la jornada laboral. Por tanto, la realización de una forma segura
y eficiente de las tareas de implementación de los cambios resulta esencial para la
calidad de los servicios y para la tranquilidad de todos. En este capítulo encontrará
las prácticas más avanzadas para lograrlo.
10. Procesos de gestión de la entrega
10.1. Gestión de la entrega 697
10.1. Gestión de la entrega
Figura 10.1.1. Esquema general del proceso de la gestión de la entrega
El nombre del proceso de gestión de la entrega, del término inglés release manage-
ment, ha tenido múltiples traducciones al castellano. También se le conoce como
gestión de despliegues, gestión de versiones, gestión de lanzamientos, gestión de
despliegue de versiones, etc. En ISO/IEC 20000 e ITIL v2 se ha traducido como
gestión de la entrega, mientras que en ITIL v3 adopta el nombre de gestión de des-
pliegues y versiones (release and deployment management) 1.
La gestión de la entrega ejecuta las acciones a realizar para producir el cambio auto-
rizado.
Los cambios se convierten en entregas una vez que han sido construidos y ha sido
aprobada su transición, por ello, toda entrega ha tenido que pasar primero por la
gestión del cambio. El proceso se activa con la recepción de la petición de cambio
aprobada (RFC) y de los elementos a instalar. Desde este momento hasta que el
cambio ha sido incorporado a la producción normal, es necesaria la intervención
1
Véase la terminología acordada por el sector en www.itsmf.es
de numerosas áreas y especialidades diferentes. En entregas grandes, el proceso

involucra a casi toda la organización, iniciándose en las áreas clientes, pasando por
desarrollo y terminando en las diversas especialidades técnicas necesarias, sin olvi-
darse de los suministradores que deben intervenir.
Lo primero que se debe tener en cuenta a la hora de planificar este proceso, es la com-
plejidad de los sistemas y servicios que se utilizan en las organizaciones. La consolida-
ción de servidores, la virtualización o las arquitecturas orientadas a servicios (SOA),
promueven una sana reutilización de infraestructuras y componentes, para aumentar
la eficiencia y agilidad del proveedor de TI, pero hacen más compleja la implementa-
ción de los cambios. Un componente puede formar parte de muchos servicios, intro-
ducir un cambio en él se hace más complejo, tanto por tener que comprobar su
impacto en todos los servicios que lo utilizan como por evitar paradas en los mismos.
La gestión de la entrega es el proceso, dentro de la gestión de servicios TI, con la res-
ponsabilidad de la puesta en producción de los cambios, minimizando el riesgo. En la
figura 10.1.2 se presenta una visión introductoria al proceso de gestión de la entrega.
Sin una correcta coordinación de la entrega y sin un proceso fiable y ágil que lo
soporte, el riesgo de fracaso es alto. Esto se traduce en la no disponibilidad de las

entrega • Orden y eficiencia en el trabajo
continuo de implementar los cambios.
• Planificación actualizada de todas los
Definición:
entregas a implementar.
Proceso que organiza y controla los • Integración de los desarrollos en el
pasos al entorno de producción de los entorno productivo.
cambios aprobados.
• Mayor control de la calidad de los
cambios implementados, mediante
Objetivo: pruebas.
Entregar, distribuir y realizar el • Información actualizada sobre lo

seguimiento de uno o más cambios en el instalado en producción.
entorno de producción real. • Colabora en el control de las versiones
del software instalado.
• Calidad en las actuaciones al disponer
de información precisa.
• Control del almacén de componentes
hardware.
Figura 10.1.2. Introducción al proceso de gestión de la entrega

aplicaciones en explotación, en el descontrol en los trabajos internos en TI y en las

consiguientes pérdidas económicas para el negocio al que se presta el servicio.
Para conseguir el objetivo del proceso, se debe controlar mediante pruebas todo lo
construido, velar por la eficiencia en la actividad de implementación, mantener una
planificación y orden en las actuaciones, gestionar con rigor el almacenamiento de
hardware y velar por que la información sobre la configuración no se desactualice
con los cambios. La figura 10.1.3 muestra estos principios básicos en los que se
sustenta el proceso.
El primer principio del proceso es el control de lo que se ha construido y que se va a

proceder a implantar. Es fundamental controlar y gestionar todos los componentes
que forman parte de una entrega, además de identificar qué política y periodicidad
se va a aplicar en el proceso. También es necesario dejar definido el procedimiento
para la gestión de entregas de emergencias (procedentes de cambios de emergencia).
Con el fin de controlar todos los cambios construidos, la gestión de la entrega lleva
a cabo la planificación, diseño, configuración y pruebas del hardware y software para
crear un conjunto de componentes funcionando en producción.
El orden y la planificación son esenciales debido a que en el ciclo de cada entrega
se debe movilizar personal de diversas áreas de la empresa y de los suministradores,
como el cliente, el jefe de proyecto, el equipo de desarrollo, el grupo de soporte al

desarrollo, el grupo de pruebas, los técnicos de producto, los técnicos de middle-
ware, los técnicos de sistemas operativos, los técnicos de servidores, los técnicos de
almacenamiento, los expertos de las redes del centro de datos, los expertos en segu-
ridad, los encargados de la distribución física del centro de datos, los suministrado-
res de servicios y productos relacionados, etc.
La eficiencia en las implantaciones es otro de los principios básicos en los que se
debe sustentar el proceso, pues el proceso de la implantación de los cambios, junto
con el de la resolución de incidentes, es uno de los procesos que más recursos
demandan de la organización de producción. Tiene un impacto directo en la agili-
dad de TI ante el ritmo del negocio y en la credibilidad por el cumplimiento de los
plazos comprometidos.
Este proceso también es responsable de que toda la información relativa a las modi-
ficaciones esté correctamente actualizada, principalmente en la CMDB y en la
DSL, encargándose de que se actualice en el resto de soportes de información
(manuales para el centro de atención al usuario, manuales de usuario, manuales téc-
nicos, etc.).
Hasta que alguien no se haya pasado horas, e incluso días, buscando, por ejemplo,
una simple tarjeta fiber channel, en una caótica sala de almacén de 200 m2, repleta
de cajas semivacías, de equipos nuevos a instalar, de equipos retirados, de repues-
tos, de palés, etc., no apreciará la importancia de mantener organizado el almacén
de componentes de hardware. Por ello, el último de los pilares de este proceso es el
rigor en la gestión del almacén de componentes de hardware para que esté siempre
ordenado y su contenido identificado e inventariado, con el fin de suministrar
los componentes necesarios y gestionar la recepción de las mercancías asociadas a los
proyectos.
La gestión de la entrega interviene en todos los cambios que se vayan a implantar,
ya sean grandes o pequeños, urgentes o planificables, como son:
• Cambios grandes o críticos de plataformas hardware.
• Despliegues de cambios en las plataformas de los usuarios: PC, PDA, teléfo-
nos inteligentes, etc.
• Despliegues de cambios en las plataformas de servidores. Actualización
de versiones del sistema operativo o de productos software. La instalación de
parches de seguridad en la plataforma de servidores es una actividad cada
vez más frecuente y que requiere una dedicación importante de recursos.
• Cambios importantes en el software.
• Multitud de cambios pequeños, que se tenderán a agrupar o asociar en uni-

dades de un tamaño manejable.
• Cambios urgentes.
Despliegue
(automatización)
Política
de entregas
Planificación
de la entrega
Metodología
de pruebas
Plataformas
de pruebas
e integración
Entrega
CMDB DSL
Lista de cambios Base de datos Biblioteca de Almacén definitivo
planificados (FSC) de gestión de software definitivo de hardware
la configuración
Figura 10.1.4. Componentes principales del proceso de gestión de la entrega

Los componentes que intervienen en el proceso de gestión del incidente son los
siguientes.
Almacén de Hardware Definitivo (DHS). Uno o varios emplazamientos dis-
puestos para el almacenamiento seguro de componentes y repuestos de hardware.
Estos componentes se gestionan con el mismo nivel que los elementos de configu-
ración hardware equivalentes del entorno de producción. El mantenimiento com-
pleto del DHS es responsabilidad directa del proceso de gestión de la entrega. En
ITIL v3, en el proceso de gestión de la configuración se habla del almacenamiento
de los recambios o repuestos definitivos (DS, Definitive Spares).
Base de Datos de Gestión de la Configuración (CMDB). Base de datos gestio-
nada por el proceso de gestión de la configuración y que el proceso de gestión de la
entrega debe actualizar con los cambios a los elementos de configuración (CI) que
realice de forma coordinada con gestión de la configuración.
Biblioteca de Software Definitivo (DSL). La gestión de la entrega debe actuali-
zar este repositorio con las últimas versiones del software implementado en produc-
ción, así como con la parametrización realizada y la documentación asociada. En
ISO/IEC 20000 la responsabilidad de este repositorio recae en gestión de la confi-
guración. Por tanto, al igual que en el caso de la CMDB, cualquier actualización en
esta biblioteca debe estar coordinada con el proceso de gestión de la configuración.
Despliegue. Es la acción de poner en producción el conjunto de cambios que con-
tiene una entrega. Es importante poner foco en la automatización de este proceso
mediante el uso de las herramientas técnicas adecuadas.
Entrega. Es un conjunto de cambios aprobados en un servicio TI, que se prueban
e introducen como conjunto en el entorno de producción. Consta del software
nuevo o modificado y del hardware nuevo o modificado. Se define por las RFC que
implementa. La entrega se caracteriza por:
• Unidad de entrega. Porciones de los servicios que normalmente se imple-
mentan a la vez. Generalmente, esta unidad es variable, dependiendo de los
tipos de elementos de software y hardware implicados
• Tipo de entrega. Se definen varias categorías de entregas en función del
impacto (mayores y menores), la urgencia (normales y emergencia) y la tasa de
renovación de elementos de configuración (completas, delta y empaquetadas).
• Identificación de la entrega. Las entregas deben estar identificadas unívo-
camente de acuerdo a un esquema definido en la política de entregas. Debe
incluir una referencia al servicio o elemento de configuración que representa
y un número de versión de hasta tres niveles (por ejemplo, servicio_
nomina_V2.3.6).
Herramienta de gestión de la entrega. Es la aplicación y bases de datos que dan

soporte informático al proceso. Muchas veces se integra con la herramienta de ges-
tión del cambio.
gramación unificada de todos los cambios en curso, que recoge los detalles de los
cambios cuya implantación haya sido aprobada, así como, las fechas propuestas
para tal implantación. La responsabilidad del mantenimiento de esta lista es del
proceso de gestión del cambio, pero gestión de la entrega debe responsabilizarse de
su actualización según se vaya avanzando en las entregas. En ITIL v3 se ha supri-
mido la palabra “forward” denominándose ahora “change schedule”.
Metodología de pruebas. Sistemática de trabajo documentada que detalla todas las
pruebas necesarias que se deben realizar en todas las etapas por las que pasan los
cambios que contiene una entrega, desde las pruebas durante la fase de construc-
ción, las pruebas en la fase de implementación (integración o transición) hasta las
pruebas de aceptación final del cambio. La metodología de pruebas es un docu-
mento único utilizado tanto para las pruebas en construcción, como para la entrega.
La gestión de la entrega es la encargada de la implementación y control de calidad
de todo el software y hardware instalado en los entornos de desarrollo, preproduc-
ción y producción.
Una alternativa, utilizada en ocasiones para validar el correcto funcionamiento
antes de desplegar y abrir el servicio a todos los usuarios, es la puesta en marcha de
lo que se denomina piloto en producción. Este piloto estaría formado por un redu-
cido grupo de usuarios reales durante un corto espacio de tiempo. Esto será posi-
ble siempre que los sistemas en explotación y el que se está probando, permitan una
conciliación de los datos y resultados.
Planificación de una entrega. Cada entrega lleva una planificación específica y
detallada, que se va completando según avanza el conocimiento de las actividades
que se van a realizar. La planificación de la entrega recoge todas las actividades que
se van a realizar con el conjunto de cambios (RFC) que contiene. En el caso de
grandes proyectos (nuevos o modificaciones), la planificación de la entrega es una
parte de la planificación global del proyecto. La planificación también recoge minu-
ciosamente la etapa crítica del paso a producción, en la que se debe reflejar hasta el
más mínimo detalle de las acciones que se van a realizar, las personas que intervie-
nen y la franja horaria de cada intervención.
Plataformas de pruebas e integración. Equipamientos informáticos que replican
las condiciones del entorno productivo en vivo. Dependiendo de la criticidad y
complejidad de los servicios, la plataforma de pruebas y la de integración serán dis-
tintas o las mismas. En la plataforma de integración (o preproducción) se realizan
la conexión del aplicativo software con el entorno real (reglas del firewall, segmenta-
ción de VLAN, integración con el middleware, automatización de tareas batch, inte-
gración en la monitorización, integración en el backup, etc.) para poder comprobar
su correcto funcionamiento antes del paso a producción regular.
Política de entrega. Define las funciones y responsabilidades principales de la ges-
tión de la entrega. Establece las pautas en toda la organización para la implementa-
ción de los cambios. Normalmente se suelen definir tres o cuatro grandes ciclos de
entrega anuales, que regula todo el mantenimiento evolutivo y correctivo de las
aplicaciones. Los cambios que no pueden asociarse a estos ciclos anuales, se gestio-
nan “al detalle” intentando agruparlos o empaquetarlos. La política de entrega debe
incluir también la numeración, frecuencia de las entregas y el nivel de infraestruc-
tura TI comprendido en las entregas. La política de entrega es parte del plan del
proceso de gestión de la entrega.
Revisión (PIR, Post Implementation Review). Comprobación técnica y funcional
que se realiza transcurrido un determinado período de tiempo tras la implantación
de la entrega y cuyo objetivo es el de validar si los efectos de los cambios han sido
los deseados, para proceder al cierre definitivo de la entrega y, consecuentemente,
de los cambios que alberga. La realiza el proceso de gestión de la entrega, la lidera
el gestor del cambio.

Las interacciones y funcionalidades de la gestión de la entrega se resumen en la
figura 10.1.5.
El inicio de la actividad de una entrega viene desencadenado por la aprobación de
la etapa de transición de una o varias RFC, lógicamente las peticiones de cambio a
implantar van acompañadas de los elementos que componen el cambio. Además, el
proceso utiliza como entradas de soporte la FSC, la CMDB, la DSL y la base de
datos de gestión del cambio.
Las principales actividades de la gestión de la entrega se resumen en:
• Establecer una política de implementación de las entregas, que marque el
ritmo con el que toda la organización construya y evolucione los servicios,
definiendo la frecuencia y el tipo de las entregas.
• Gestionar el ciclo de vida completo de las entregas, desde su planificación
detallada, pasando por las pruebas, hasta el despliegue en producción.
• Actualizar la lista de cambios planificados (FSC).
Desencadenantes 3 Definición de la política de Salida principal:

del proceso: entrega. Ü Entrega implementada:
Ü RFC con la transición 3 Gestionar el ciclo de vida • FSC actualizado.
autorizada por completo de las entregas, desde
• DSL actualizada.
gestión del cambio. el RFC aprobado hasta su cierre.
• CMDB actualizada.
Ü Los elementos que • Actualizar la lista de cambios
componen el cambio planificados (FSC). Ü PIR enviado a gestión
construido. del cambio.
• Actualizar la CMDB y la DSL.
ÜAlmacén de HW
Entradas del soporte: 3 Actuación en entregas de gestionado (DHS).
Ü FSC anterior. emergencia.
Salidas secundarias:
Ü DSL. 3 Gestionar el almacén de
hardware (DHS). Ü Informes de errores en
Ü CMDB.
las pruebas.
Ü DHS. 3 Supervisión funcionamiento del
proceso. Mejora del proceso. Ü Propuesta de actividades
Ü BD de gestión para la mejora del
del cambio. 3 Informes y análisis sobre las
servicio.
actividades del proceso.
• Asegurar, en colaboración con la gestión del cambio y gestión de la configu-

ración, que todos los cambios se ven correctamente reflejados en la CMDB.
• Archivar copias idénticas al software en producción, así como, de toda su
documentación asociada, en la biblioteca de software definitivo (DSL).
• Actuación ante las entregas de emergencia, provenientes de cambios de
emergencia.
• Gestionar y mantener actualizado el almacén de repuestos hardware o Alma-
cén de hardware definitivo (DHS).
• Supervisión del correcto funcionamiento de todo el proceso. Realización de
las propuestas de mejora al plan unificado de mejora del servicio (véase el
capítulo 4).
• Realización de informes y análisis sobre las actividades del proceso.
La salida principal del proceso es la implementación de la entrega con éxito y

cerrada mediante la revisión postimplementación (PIR) que se envía a la gestión
del cambio. También se obtiene el almacén de hardware gestionado y actualizado,
la planificación de cambios (FSC), la biblioteca de software definitivo (DSL) y la

base de datos de gestión de la configuración (CMDB).
Como otras salidas se obtienen:
• Plan de gestión de la entrega.
• Plan detallado de la política de entrega, procedimientos, responsables, res-
tricciones y dependencias, etc.
• Comunicación al proceso de gestión de la configuración.
• Comunicación al proceso de gestión del cambio.
• El contenido del registro de la entrega: resultados de las pruebas, aceptacio-
nes, implementación, etc.
• Comunicación a gestión de la capacidad.
• Informes que se soliciten.
• Informes de errores en las pruebas.
• Informes para la evaluación y mejora continua del proceso y para el segui-
miento y monitorización periódico del proceso.
• Y una propuesta de actividades para la mejora del servicio.
La entrega
Se define como entrega a una colección de hardware, software, documentación,
procesos u otros componentes requeridos para implementar uno o más cambios
aprobados a los servicios de TI. Los contenidos de cada entrega son administrados,
probados e implementados como una única entidad (Glosario ITIL v3, OGC).
Las entregas se suelen clasificar según su impacto en la infraestructura TI, en las
siguientes categorías:
• Entregas mayores. Representan importantes despliegues de software y hard-
ware, y que introducen modificaciones importantes en la funcionalidad,
características técnicas, etc.
• Entregas menores. Suelen implicar la corrección de errores conocidos pun-
tuales. Su tamaño reducido no exime que se implementen de una manera
procedimentada y correctamente documentada.
En función de la urgencia para su implantación:

• Entregas normales. Siguen el ciclo de vida de la entrega y van ordenadas
por su categoría y prioridad.
• Entregas de emergencia. Modificaciones muy urgentes que reparan de

forma inmediata un error conocido grave. Estas entregas se caracterizan por
la rapidez de actuación necesaria, lo cual no exime de obtener los permisos y
aprobaciones establecidos para los cambios de emergencia/urgencia. Una vez
pasada la urgencia, se procederá a adecuar y completar la documentación y
el resto de acciones que hubiera que haber realizado si no se hubiera actuado
de emergencia (CMDB, DSL, etc.).
Atendiendo a la tasa de renovación de los elementos de configuración de un servi-

cio, las entregas se dividen en los tipos siguientes:
• Entregas completas. Renuevan todos los elementos de configuración a la
vez, por lo que no hay problemas de inconsistencias entre los componentes
nuevos o modificados y los antiguos del servicio.
• Entregas delta. Únicamente se renueva una parte de la funcionalidad, y sólo
se incluyen en la entrega los elementos de configuración afectados para la
modificación realizada.
• Entregas empaquetadas. Son agrupaciones de cambios (completos o delta)
con el fin de reducir el número de veces que se realizan cambios en el entorno
productivo. En algunos casos esta opción es obligada por incompatibilidades
entre una nueva versión con software o hardware previamente instalado. Por
ejemplo, en la migración a un nuevo sistema operativo que requiriese hard-
ware más avanzado y/o nuevas versiones de los programas ofimáticos.
Es necesario establecer unas reglas de numeración de las diversas versiones de los

elementos de configuración. El sistema universalmente aceptado es, utilizar una
codificación alfabética para identificar el elemento de configuración y una numé-
rica de tres niveles para la secuencia de versiones por las que pase el elemento.
En un instante determinado un elemento de configuración puede tener simultáne-
amente varias versiones en diversas fases de su ciclo de vida: desarrollo, pruebas,
producción y archivado.

La planificación e implementación del proceso de la entrega la realizará el mismo
equipo especialista en procesos TI que se encarga de la definición de las formas de
trabajar en toda la organización. La implementación del proceso forma parte de la
implementación de sistema de gestión de TI (SGSTI, véase el capítulo 3). La imple-
mentación del SGSTI y, por ende de este proceso, se realizará siguiendo el rigor del
ciclo PDCA establecido en el “proceso de implementación de la gestión del servi-

cio” (véase el capítulo 4). Este equipo de procesos colaborará estrechamente con el
futuro responsable de gestión de la entrega. A este respecto, las Normas ISO/IEC
20000 establecen un marco de actuación.
UNE-ISO/IEC 20000-1
Nota: El proceso de gestión de la entrega se debería integrar con los procesos de gestión de la configu-
ración y de gestión del cambio.
El proveedor del servicio debe planificar con el negocio la entrega de los servicios,
sistemas, software y hardware. Los planes sobre cómo desplegar una entrega se
deben acordar y autorizar por todas las partes pertinentes, por ejemplo clientes,
usuarios, personal de operaciones y de soporte.
UNE-ISO/IEC 20000-2
La gestión de la entrega debería coordi- entrega, por ejemplo: procesos de

nar las actividades del proveedor del negocio, documentos de soporte y
servicio, los diferentes proveedores y el acuerdos de nivel de servicio.
negocio para planificar y desplegar una Se debería evaluar el impacto de todos
entrega a lo largo de un entorno distri- los elementos de configuración nuevos
buido. o cambiados requeridos para efectuar
Son esenciales una buena planificación los cambios autorizados.
y gestión para empaquetar y distribuir El proveedor del servicio se debería ase-
una entrega con éxito, y para gestionar gurar de que los aspectos técnicos y no
los impactos y riesgos asociados para el técnicos de la entrega son considerados
negocio y para TI. Se debería planificar conjuntamente.
con el negocio la entrega de los siste-
Los elementos de la entrega se deberían
mas de información, infraestructuras,
poder ser trazables y no modificables.
servicios y documentación afectados.
Solo se deberían aceptar en el entorno
Todas las actualizaciones asociadas a la de producción las entregas adecuadas,
documentación se deberían incluir en la probadas y aprobadas.
Los principales aspectos que se deben tener en cuenta en la implementación del

proceso son los siguientes:
• Un firme compromiso de la organización con la gestión de la entrega y sus
responsables.
• Una clara asignación de responsabilidades para que la organización de TI

acepte sin dudas la figura del gestor de la entrega dominante en todo el pro-
ceso de implementación del cambio.
• La adopción de una metodología de desarrollo que regule todo el ciclo de
construcción.
• La adopción de una metodología de gestión de proyectos eficiente que
armonice las actividades de desarrollo de software y de construcción de
infraestructuras.
• La adopción de un modelo de documentación estructurado que se convierta
en una ayuda online para toda la organización.
• La necesidad de definir una política de entrega que marque el ritmo de cons-
trucción en toda la organización.
• La existencia de entornos de pruebas e integración reales y válidos que per-
mitan la extrapolación de datos de forma empírica, para garantizar el com-
portamiento del despliegue en producción.
• La realización de pruebas de capacidad y de regresión en las nuevas versio-
nes de software y hardware, para lo cual es necesario el soporte de las herra-
mientas técnicas adecuadas.
• La posible necesidad de crear un almacén organizado de hardware.
• Las herramientas de soporte a la gestión de la entrega. Habitualmente se uti-
liza integrada con la herramienta de gestión del cambio.
• La necesidad de herramientas técnicas para automatizar los despliegues en la
plataforma de PC, en los dispositivos de mano de los usuarios y en los servi-
dores.
• La resistencia de la organización a cumplir la política de entrega, introdu-
ciendo los cambios por el procedimiento de emergencia.
• Un adecuado plan de comunicación que informe a todos los responsables y
usuarios de la organización TI de las ventajas de una correcta gestión de todo
el proceso de cambio.
• La implementación sincronizada de versiones en entornos altamente distri-
buidos.
• Los costes originados para la gestión habitual del proceso:
– De personal y servicios para mantener los entornos, integración, prepro-
ducción o pruebas.
– Del almacén definitivo de hardware (DHS).

– Coste de hardware y herramientas software, así como su soporte.
En la implementación del proceso hay que considerar las relaciones con otros pro-
cesos. La gestión de la entrega, está estrechamente ligada con la gestión de la confi-
guración y la gestión del cambio:
• Gestión de la configuración, para asegurar que toda la información relativa a
las nuevas versiones se integra adecuadamente en la CMDB, de forma que
ésta se halle correctamente actualizada y ofrezca una imagen real de la confi-
guración de la infraestructura TI.
• Gestión del cambio: la gestión de la entrega tiene la responsabilidad de
implementar las entregas acordadas por el comité de cambios. La gestión del
cambio es la encargada de aprobar y supervisar todo el proceso, pero es tarea
específica de la gestión de la entrega el diseñar, poner a prueba e instalar en
el entorno de producción los cambios preestablecidos.
La gestión de la entrega también debe mantener actualizada la Biblioteca de soft-

ware definitivo (DSL), donde se guardan copias de todo el software en producción,
y el Almacén de hardware definitivo (DHS), donde se almacenan los equipos a ins-
talar y las piezas de repuesto para la rápida reparación de problemas de hardware en
el entorno de producción.
También se relaciona con otros procesos, como con el proceso de gestión de sumi-
nistradores que tiene como objetivo gestionar los suministradores para garantizar
la provisión sin interrupciones de servicios de calidad.
Política de entrega
La principal misión de la política de entrega es que toda la organización entienda y
asuma la función de la entrega y su alto nivel de implicación y responsabilidad en la
construcción y evolución de los servicios, una vez aprobados por la gestión del
cambio. La política de entrega se debe realizar alineada con la política de construc-
ción de servicios y la estrategia de TI.
UNE-ISO/IEC 20000-1
Se debe documentar y acordar la política de entrega que establezca la frecuencia y

el tipo de las entregas.
UNE-ISO/IEC 20000-2
Debería existir una política de entrega

que incluya: e) una aproximación en torno a la
agrupación de los cambios en
a) la frecuencia y tipos de entregas; una entrega;
b) los roles y las responsabilidades f) una aproximación para la auto-
para la gestión de la entrega; matización de los procesos de
c) la autoridad para pasar la entrega construcción, instalación, y distri-
a los entornos de pruebas de acep- bución de la entrega para ayudar
tación y de la producción; a su repetibilidad y a su eficiencia;
d) una identificación y descripción g) la verificación y la aceptación de
única para todas las entregas; una entrega.
La política de entrega define para toda la organización la forma en que se construi-

rán e implementarán los cambios correctivos y evolutivos de los servicios. La polí-
tica de entregas contiene las directrices que se deben cumplir, tanto por los partici-
pantes en el proceso, como por el resto de la organización. También define la
numeración y frecuencia de las entregas, los criterios para las entregas de emergen-
cia, etc.
La política de entrega forma parte de la planificación e implementación del proceso
de entrega. Vela especialmente por el equilibrio entre la necesidad de unos plazos
adecuados de evolución, la estabilidad de los servicios, la carga de trabajo de la
organización de TI y los costes.
Las organizaciones más avanzadas definen tres o cuatro ciclos anuales de puesta en
producción en los que se agrupa toda la entrega del software y hardware evolutivo y
correctivo. En un momento determinado del tiempo, puede existir un ciclo en fase
de diseño, otro en construcción y otro en pruebas. Así, los grandes pasos a produc-
ción sólo se realizan en tres o cuatro momentos pactados del año. Con esto se con-
sigue que la organización de TI trabaje de una forma síncrona.
En la figura 10.1.6 se presentan las directrices para el diseño de la política de
entrega.
Ciclo de vida completo de una entrega

La gestión de la entrega ejecuta todas las actividades necesarias para llevar a cabo
con éxito y eficiencia la implantación de los cambios.
Política de entrega
• Objetivo del proceso.

• Alcance dentro de la organización de TI.
• Requisitos esperados del proceso.
• Alineamiento con la estrategia de TI y la
política de construcción de servicios.
• Relación con desarrollo y gestión del cambio.
• Metodología de pruebas.
• Frecuencia y tipos de entregas.
• Política de numeración de entregas.
• Calendario anual de entregas mayores.
Implant.
Dis. Constr. Pru.
Dis. Constr. Pru.
Dis. Constr. Pru.
• Gestión y agrupación de las entregas menores.

• Criterios para las entregas de emergencia.
• Etc.
Figura 10.1.6. Esquema de una política de entrega
El ciclo de vida completo de una entrega comienza una vez que el cambio ha sido
construido, aceptado por el equipo técnico y aprobada su implementación por la
gestión del cambio. En la figura 10.1.7 se presenta el ciclo típico de una entrega.
El ciclo de vida completo de una entrega se resume en:
• La gestión del cambio (el gestor o el CAB) aprueba la implantación del cam-
bio construido. La aprobación actúa como desencadenante del proceso de
gestión de la entrega.
• Se realiza la aceptación y revisión preliminar del cambio construido. Se rea-
liza la primera planificación, acorde con lo previsto en el proyecto de cons-
trucción.
Figura 10.1.7. Ciclo de vida de una entrega
• Se realizan las pruebas de instalación, las funcionales, las técnicas, las de

explotación y se revisa la documentación. En esta etapa se realizan las prue-
bas de carga para garantizar la escalabilidad de lo construido y comprobar la
capacidad necesaria prevista.
• Superadas las pruebas y subsanados los defectos se realizaría, si procede, la
integración en el entorno de preproducción.
• Se solicita a la gestión del cambio la autorización para la implementación en
producción.
• Desplegar las nuevas versiones de los elemento de configuración de software
y de hardware en el entorno de producción. Garantizar que las entregas no
sufren manipulación, fuera de su configuración específica, en el proceso de
despliegue por los diferentes entornos.
• Realizar la formación necesaria a los usuarios y técnicos para que sean capa-
ces de gestionar los nuevos servicios.
• Garantizar y ejecutar un plan de marcha atrás a un punto consistente si la
entrega no tuviera éxito.
• Comunicar y formar a los clientes y usuarios sobre las funcionalidades de
la nueva versión.
• Comunicar y formar a los técnicos y responsables de producción sobre la
operación de la nueva versión, errores conocidos o cambios en los niveles
de servicio.
• Actualizar la CMDB, DSL y DHS. Es fundamental garantizar que se han
actualizado correctamente estos repositorios.
• Realizar la verificación postimplementación de la entrega y comunicárselo a
la gestión del cambio.
Planificación de una entrega. Lo primero para decidir cuándo y cómo realizar

una entrega es analizar la categorización del cambio, evaluando si es de emergencia
o es un cambio normal dentro de la planificación pactada de antemano. En
segundo lugar, las entregas vienen con la categoría y prioridad asignadas en la ges-
tión del cambio.
Cada entrega debe tener una planificación que comprenda todas las etapas del
ciclo de vida: la pruebas, la integración, la preparación del despliegue, el paso al
entorno productivo (incluyendo los planes de marcha atrás) y la revisión postim-
plementación.
Es necesario establecer un marco general para planificar las entregas que fije una
sistemática rápida de trabajo. Esto es especialmente importante para los casos de
entregas menores y de emergencia, pues en el caso de entregas de gran enverga-
dura, se deben desarrollar planes específicos que tomen en cuenta las peculiarida-
des de cada caso.
UNE-ISO/IEC 20000-1
El proveedor del servicio debe planificar con el negocio la entrega de los servicios,
sistemas, software y hardware. Los planes sobre cómo desplegar una entrega se
deben acordar y autorizar por todas las partes pertinentes, por ejemplo clientes,
usuarios, personal de operaciones y de soporte.
El proceso debe incluir la forma en que se de marcha atrás o se corrija la entrega si
no se realiza con éxito.
Los planes deben registrar los entregables y las fechas de la entrega, y hacer refe-
rencia a las peticiones de cambio, errores conocidos y problemas relacionados.
El proceso de gestión de la entrega debe proporcionar la información adecuada al
proceso de gestión del incidente.
Las peticiones de cambio se deben evaluar en cuanto a su impacto en los planes de
entregas. Los procedimientos de gestión de la entrega deben incluir la actualización
y el cambio de la información de configuración y los registros de cambio. Las entre-
gas de emergencia se deben gestionar de acuerdo a un proceso definido que rea-
lice la interfaz con el proceso de gestión del cambio de emergencia.
ISO/IEC 20000-2 detalla los contenidos que se deben contemplar en la planifica-

ción de una entrega.
UNE-ISO/IEC 20000-2
El proveedor del servicio debería traba- errores conocidos que hayan sido
jar conjuntamente con el negocio para identificados durantes las pruebas
asegurar que los elementos de configu- de la entrega;
ración que se van a desplegar en una c) los procesos relacionados para la
entrega son compatibles entre sí y con implementación de una entrega a
los elementos de configuración del lo largo de todo el negocio y las
entornode destino.
diferentes unidades geográficas;
La planificación de la entrega debería
d) el modo en el que se dará mar-
asegurar que los cambios de los siste-
cha atrás de la entrega o en que
mas de información, infraestructuras,
esta se remediará si no se con-
servicios y documentación afectados
cluye con éxito;
son acordados, autorizados, planifica-
dos, coordinados y que se realiza un e) los procesos de verificación y acep-
seguimiento de los mismos. tación;
La entrega y el despliegue se deberían f) la comunicación, preparación,
planificar en etapas ya que los detalles documentación y formación para
del despliegue podrían no ser conoci- los clientes y personal de apoyo;
dos inicialmente. g) la logística y los procesos implica-
La planificación de una entrega y del dos para realizar la compra, el
despliegue normalmente debería incluir: almacenamiento, la expedición, la
a) las fechas de la entrega y la des- conexión, la aceptación y la puesta
cripción de los entregables; a disposición de los bienes;
b) los cambios y problemas relacio- h) los recursos de apoyo necesarios
nados, errores conocidos cerra- para asegurar el mantenimiento
dos o resueltos por esta entrega y de los niveles de servicio;
i) la identificación de las dependen- k) el calendario de auditorías del

cias, los cambios relacionados y entorno de producción cuando
los riesgos asociados que pueden sea necesario asegurar, para
perjudicar el paso sin complica- actualizaciones de gran tamaño,
ciones de una entrega a los entor- que el entorno de producción
nos de pruebas de aceptación y está en el estado esperado en el
de producción; momento de instalar la entrega.
j) la autorización de la entrega;
De todas las etapas planificadas en la entrega, el paso al entorno productivo es la

más crítica, pues debe minimizar los tiempos de parada del servicio y orquestar
la participación de los técnicos y áreas cliente. Con frecuencia, el paso a producción
se realizará fuera del horario del servicio (nocturno o fin de semana), por lo que es
necesario detallar en cada actividad quién la realizará y en qué momento. Hay que
comunicar anticipadamente a los técnicos y al área cliente su participación y hora-
rio previsto de intervención. También es necesario disponer del teléfono de con-
tacto de cada participante, para poder engranar las actividades en el caso de inter-
venciones remotas.
Estos factores cobran una especial relevancia en situaciones en las que no se dis-
pone de una ventana temporal prefijada para el mantenimiento, o esta es más
pequeña que el tiempo estimado para intervención. Aplicando estas acciones el
impacto negativo en el servicio se puede mitigar, para que afecte lo menos posible
a los usuarios y al negocio.
A la hora de planificar correctamente el lanzamiento de una nueva entrega se deben
tomar en cuenta los siguientes factores:
• Cómo puede afectar la nueva versión a otras áreas del entramado de TI.
• Qué CI se verán directa o indirectamente implicados durante y tras el lanza-
miento de la nueva versión.
• Cómo ha de construirse el entorno de pruebas para que éste sea fiel reflejo
del entorno de producción.
• Qué planes de marcha atrás son necesarios.
• Cómo y cuándo se deben implementar los planes de marcha atrás para mini-
mizar el posible impacto negativo sobre el servicio y la integridad del sistema.
• Cuáles son los recursos humanos y técnicos necesarios para llevar a cabo la
implementación de la nueva versión con garantías de éxito.
• Quiénes serán los responsables directos en las diferentes etapas del proceso.
• Qué planes de comunicación y/o formación deben desarrollarse para que los
usuarios estén puntualmente informados y puedan percibir la nueva versión
como una mejora.
• Qué tipo de despliegue es el más adecuado: completo, delta, sincronizado en
todos los emplazamientos, gradual.
• Cuál es la vida media útil esperada de la nueva versión.
• Qué planes de comunicación y/o formación deben desarrollarse para que los
técnicos y responsables de producción puedan operar y explotar esta nueva
versión.
• Qué impacto puede tener la entrega en la calidad del servicio y en los niveles
de servicio acordados.
• Informar del modelo de operación, para la resolución de errores conocidos,
o posibles incidentes en la producción.
• Si es posible establecer métricas precisas que determinen el grado de éxito
del lanzamiento de la nueva versión.
Los elementos de configuración principales que se deben controlar en la entrega

son:
• Software:
– Software desarrollado independientemente de su naturaleza: propio, están-
dar, desarrollado a medida, etc.
– Utilidades, sistemas y herramientas software. Todo aquello que se deno-
mina software de base.
– El soporte y mantenimiento de los productos, bien por los fabricantes o
bien por un tercero que proporcione el soporte a toda la solución defi-
niendo un servicio a tal fin.
• Hardware:
– Las especificaciones del hardware.
– Las instrucciones de ensamblaje y los manuales de instalación.
– Documentación, manuales de uso de configuración, soporte y manteni-
miento.
– Contrato de mantenimiento, garantías, soportes, relación de proveedores
y fabricantes, etc.
• Comunicaciones y elementos de seguridad:

– Redes de comunicaciones que intervienen. Segmentación interna de redes
necesaria (VLAN).
– Configuración de los elementos de seguridad (firewalls, etc.).
• Documentación:
– Aplicaciones, sistemas, herramientas, utilidades, hardware, etc.
• Control y gestión:
– Inclusión en los sistemas de monitorización y alertas.
– Inclusión en los sistemas de gestión del servicio.
• Personas:
– Técnicos que deberán intervenir.
– Personas del área cliente o usuarios que deberán participar para validar los
resultados.
Pruebas e integración de la entrega. Se debe disponer de un entorno indepen-

diente para realizar las pruebas y la integración de los desarrollos en un entorno
idéntico al productivo real. En ocasiones, el entorno de integración es indepen-
diente del de prueba; en este caso se le suele denominar preproducción.
Un protocolo bien planificado de pruebas es absolutamente indispensable antes de
lanzar al entorno de producción una nueva versión con garantías de éxito.
Las pruebas no sólo deben limitarse a una validación de carácter técnico (ausencia
de errores), sino que también, deben realizarse pruebas funcionales con usuarios
reales, para asegurarse de que la versión cumple los requisitos establecidos y es
razonablemente utilizable.
Las arquitecturas de desarrollo normalizadas juegan un papel clave para garanti-
zar que se utilizan soluciones y servicios estandarizados en las organizaciones,
permitiendo la integración de productos de terceros y facilitando que no se pro-
duzcan duplicidades de una misma funcionalidad, lo que redunda en una crea-
ción y mantenimiento de servicios mucho más rápida y eficiente. Gracias a este
tipo de arquitecturas se pueden crear entornos de pruebas de integración efi-
cientes que permiten el enganche de los nuevos desarrollos con los servicios
estándar ya existentes, facilitando su prueba y certificación de un funciona-
miento adecuado.
UNE-ISO/IEC 20000-1
Se debe establecer un entorno controlado de pruebas de aceptación para construir

y probar todas las entregas previamente a su distribución.
UNE-ISO/IEC 20000-2
Se deberían verificar en el momento de El proceso completo se debería docu-

la recepción, las entregas de sistemas mentar en el plan de gestión de la con-
de información y de software provenien- figuración.
tes de equipos de desarrollo propios,
desarrolladores de sistemas, integrado-
res u otras organizaciones.
Es importante que los planes de pruebas incluyan también la prueba de los planes
de marcha atrás, para asegurar la posibilidad de volver a la última versión estable
de una forma rápida, ordenada y sin pérdida de información valiosa.
Las principales actividades realizadas en el proceso de prueba deben incluir:
• Pruebas del correcto funcionamiento de la versión en un entorno realista.
• Pruebas de integración con la versión en producción. Si se realiza un desplie-
gue fragmentado en el entorno de producción, será necesario realizar las
pruebas con las versiones operativas.
• Pruebas de regresión si fueran necesarias en preproducción.
• Pruebas de capacidad en el entorno de preproducción.
• Pruebas de los procedimientos automáticos o manuales de instalación.
• Listas de errores detectados, si se diera el caso.
• Pruebas de los planes de marcha atrás.
• Documentación para usuarios, técnicos de soporte y desarrolladores.
Diseñar, construir, documentar y configurar una entrega. Dependiendo del

tipo de entrega, puede ser necesario el empaquetado para la distribución de una
entrega. También puede ser necesaria la preparación de programas o scripts que eje-
cuten secuencias de comandos para la instalación. Se suelen utilizar herramientas
que automatizan el despliegue de las versiones de los productos software. Tanto la
entrega, como su empaquetado y distribución se debe preparar para que se man-

tenga la integridad de los servicios.
UNE-ISO/IEC 20000-1
Las entregas y su distribución se deben diseñar e implementar de forma que la inte-

gridad del hardware y del software se mantenga a lo largo de la instalación, la mani-
pulación, el empaquetado y la provisión.
UNE-ISO/IEC 20000-2
Los procesos de gestión de la entrega y la plataforma de destino satisface

distribución se deberían diseñar e imple- los requisitos previos;
mentar para: f) habilitar verificaciones que com-
a) asegurar que existe conformidad prueben que una entrega está
con la arquitectura de sistemas, la completa cuando llega a su des-
gestión del servicio y las normas tino.
de infraestructura del proveedor
del servicio; Las salidas de este proceso deberían
incluir las notas de la entrega, las ins-
b) mantener la integridad durante la
trucciones de instalación y el software
construcción, instalación, manipu-
y hardware ya instalados, en relación
lación, empaquetado y entrega;
a la línea de referencia de la configu-
c) usar bibliotecas de software y repo- ración.
sitorios relacionados para gestio-
nar y controlar los componentes Las salidas de la entrega se deberían
durante los procesos de construc- entregar al grupo responsable de las
ción y de entrega; pruebas.
d) asegurar que los riesgos estén Los procesos de construcción, gestión
claramente identificados y que se de la entrega y distribución se deberían
pueden llevar a cabo acciones de automatizar para reducir errores, ase-
recuperación si se requieren; gurando que el proceso es repetible y
e) habilitar verificaciones antes de la que se pueden desplegar rápidamente
instalación para comprobar que las nuevas entregas.
La construcción de la entrega debe incluir todos los scripts de instalación impres-

cindibles para el despliegue de la versión. Los scripts encadenaran secuencias de
actuaciones, que evitarán errores humanos. Estos scripts deberán tener en cuenta
aspectos tales como:
• Recuperación automática de datos a un punto de retorno estable.
• Actualizaciones necesarias de las bases de datos asociadas.

• Instalación de las nuevas versiones en diferentes sistemas o emplazamientos
geográficos.
• Creación de registros de actividad asociados al proceso de instalación (logs
del proceso).
• Herramienta para la distribución de software utilizada por la organización.
Destacar que también debe ser parte integrante del desarrollo los planes de marcha
atrás asociados. Estos tendrán que tomar en cuenta la disponibilidad acordada con
los clientes en el SLA.
Es necesario que todo procedimiento de entrega, genere un histórico de su resultado.
La documentación de las entregas debe seguir un patrón uniforme definido. La
metodología de desarrollo o construcción utilizada, debe contemplar la descripción
de la documentación a utilizar. Los modelos de documentación deberán adecuarse
al tipo de entrega, centrándose en que la documentación de la entrega contenga
todos los apartados de utilidad. Con frecuencia se utiliza el mismo patrón de docu-
mentación para una gran entrega que para cambios sencillos, resultando bastante
pesada e inútil.
La documentación va evolucionando desde archivos de texto aislados, hacia siste-
mas documentales integrados. Cada vez es más frecuente, que la documentación de
los servicios y sus evoluciones se estructuren en un sistema web que se convierte en
una ayuda o consulta online accesible de forma selectiva por todas las partes de la
organización.
UNE-ISO/IEC 20000-2
La documentación apropiada debería los procedimientos de instalación

estar disponible en su totalidad y alma- y de soporte, las ayudas para el
cenada según la gestión de la configu- diagnóstico y las instrucciones de
ración en referencia al elemento de operación y administración;
configuración desplegado. Esta docu- c) los procesos de construcción,
mentación debería incluir: despliegue de versiones, instala-
ción y distribución;
a) la documentación de apoyo, por
ejemplo, los acuerdos de nivel de d) los planes de contingencia y mar-
servicio; cha atrás;
b) la documentación de apoyo, por e) la planificación de la formación
ejemplo, el esquema del sistema, para los responsables del servi-
cio, el personal de apoyo y los relacionadas de la verificación y

clientes; la aceptación.
f) una línea de referencia de la confi- Si un sistema o servicio no cumple com-
guración para la entrega, inclu- pletamente con los requisitos especifica-
yendo elementos de configuración dos para él, antes de pasar a produc-
asociados tales como documenta- ción se debería identificar y registrar
ción del sistema, entornos de prue- mediante la gestión de la configuración
bas, documentación de pruebas y y la gestión del problema.
versiones de las herramientas de La información sobre errores conocidos
construcción y desarrollo; se debería comunicar a la gestión del
g) los cambios, problemas y errores incidente.
conocidos relacionados; Si la entrega es rechazada, retrasada o
h) las evidencias de la autorización cancelada, se debería informar a la
de la entrega y las evidencias gestión del cambio.
Verificación y aceptación de la entrega. Antes de proceder a su implementación

en el entorno productivo, la entrega pasa por un proceso formal de verificación de
que se han cumplido todos los requisitos establecidos, para solicitar posteriormente
a gestión del cambio su autorización para proceder al despliegue en el entorno de
producción de la explotación regular. Las comprobaciones que requiere ISO/IEC
20000-2 son las que se muestran a continuación:
UNE-ISO/IEC 20000-2
El resultado final debería ser una apro- usando el proceso de producción

bación basada en el grado en el que el planificado;
paquete completo de la entrega recoge c) verificar que se ha completado el
la totalidad de los requisitos. nivel adecuado de pruebas, por
Los procesos de verificación y acepta- ejemplo, pruebas funcionales y no
ción deberían: funcionales, pruebas de acepta-
a) verificar que el entorno contro- ción por el negocio, pruebas en
lado de las pruebas de acepta- los procedimientos de construc-
ción se ajusta a los requisitos del ción, despliegue de versiones, dis-
entorno de producción de des- tribución e instalación;
tino; d) asegurar que la entrega es pro-
b) asegurar que la entrega se ha cre- bada a la satisfacción de los
ado a partir de versiones bajo el clientes del negocio y del perso-
control de gestión de la configura- nal del proveedor del servicio;
ción y que se han instalado en el e) asegurar que la autoridad apro-
entorno de pruebas de aceptación piada en cuanto a la gestión de la
entrega aprueba cada etapa de los requisitos previos de software y

las pruebas de aceptación; hardware;
f) verificar antes de la instalación que g) verificar que la entrega está com-
la plataforma de destino satisface pleta cuando llega a su destino.
Despliegue, distribución e instalación. Superada la fase de validación o las prue-

bas, la gestión del cambio será la encargada de proporcionar la autorización final a
la entrega para que se proceda a su instalación.
La distribución de la nueva versión, también conocida como rollout, puede ser de
varios tipos:
• Completa y sincronizada: se realiza de manera integral y simultánea en todos
los emplazamientos.
• Fragmentada: ya sea bien espacial o temporalmente. Por ejemplo, introdu-
ciendo la nueva versión por grupos de trabajo o incrementando progresiva-
mente la funcionalidad ofrecida.
UNE-ISO/IEC 20000-2
Se debería revisar el plan de despliegue laciones físicas, el entorno, las

y se deberían añadir detalles, si es nece- instalaciones eléctricas y otros
sario, para asegurar que se van a llevar servicios;
a cabo todas las actividades necesarias. d) se notifican las nuevas entregas al
personal del negocio y del prove-
Es importante que la entrega sea pro-
edor del servicio;
porcionada de un modo seguro para su
e) se eliminan los productos, servi-
destino en el estado esperado. Los pro-
cios y licencias que quedan sin
cesos de despliegue, distribución e ins-
utilidad tras la nueva entrega.
talación deberían asegurar que:
a) todas las zonas de almacena- Después de una distribución de software
miento de hardware y software son en una red es esencial comprobar que
seguras; la entrega está completa y es operativa
b) existen procedimientos adecuados cuando llega a su destino.
para el almacenamiento, expedi- Los registros de activos y de la gestión
ción, recepción y eliminación de de la configuración se deberían actuali-
bienes; zar con la ubicación y el propietario del
c) se planifican y completan las software y el hardware tras una instala-
comprobaciones sobre las insta- ción llevada a cabo con éxito.
Se debería usar un cuestionario de satis- Todos los resultados de las encuestas de

facción y aceptación por parte del satisfacción de los clientes deberían
cliente de la instalación para registrar el constituir una realimentación para la
éxito o el fracaso de dicha instalación. gestión de las relaciones con el negocio.
El procedimiento de rollout debe ser documentado y comunicado a todas las partes

implicadas para que conozcan sus tareas y responsabilidades específicas. En parti-
cular los usuarios finales deben estar puntualmente informados del calendario de
despliegue y de cómo éste puede afectar a sus actividades diarias, y en algunos
casos, en función de su complejidad, puede ser necesario establecer un plan de for-
mación específico.
Es imprescindible determinar claramente:
• Los CI que deben borrarse e instalarse y en qué orden debe realizarse este
proceso.
• Cuándo debe realizarse este proceso para diferentes grupos de trabajo y/o
localizaciones geográficas.
• Que métricas o eventos determinan la puesta en marcha de los planes de
marcha atrás y si estos deben ser completos o parciales.
Tras la distribución, la gestión de la entrega debe asegurarse de que:

• Se incluya una copia de la versión en la DSL.
• El DHS incorpore repuestos esenciales de los nuevos CI.
• La CMDB esté correctamente actualizada.
• Los usuarios estén debidamente informados de las nuevas funcionalidades y
hayan recibido la formación necesaria para poder sacar el adecuado prove-
cho de las mismas.
• Los técnicos y responsables de producción están correctamente informados
y formados para garantizar la operación.
Tras la implementación, la gestión de la entrega debe ser puntualmente informada

por el centro de servicio al usuario de los comentarios, quejas, incidentes, etc. que
la nueva versión haya podido suscitar.
Toda información obtenida deberá ser analizada para asegurar que las próximas ver-
siones incorporen las sugerencias recibidas y que se tomen las medidas correctivas
necesarias para minimizar el impacto negativo que puedan tener futuros cambios.
Comunicación y formación. Salvo contadas excepciones, es necesaria la interac-

ción usuario-aplicación y ésta suele representar el eslabón más débil de la cadena.
Es frecuente, y a su vez un grave error, que cuando se aborden cuestiones de carác-
ter técnico se obvie el factor humano. Es inútil disponer de un sofisticado servicio
TI si los usuarios, debido a una incompleta formación, no se encuentran en dispo-
sición de aprovechar sus ventajas.
En cambios menores, será suficiente con informar a los usuarios.
En nuevos servicios o cambios radicales, la formación adquiere una relevancia
importante y debe estructurarse en distintos niveles:
• Los usuarios deben conocer las entregas que se van a implementar y conocer
con anterioridad la nueva funcionalidad planificada o los errores que se pre-
tenden resolver para participar, a su discreción, en el proceso.
• Siempre que sea posible, las pruebas de carácter funcional deben ser realiza-
das por un grupo de usuarios finales (conviene seguir disciplinas tipo focus
group para captar la opinión de los usuarios). Durante este proceso de
prueba se documentarán y analizarán:
– La experiencia subjetiva de usuario.
– Los comentarios y sugerencias sobre usabilidad y funcionalidad.
– Las dudas que hayan surgido durante el uso de la nueva versión.
– La claridad de la documentación que se pondrá a disposición del usuario
final.
• Cuando se considere oportuno se impartirán cursos presenciales o remotos

mediante módulos de e-learning, sobre el funcionamiento de la nueva versión.
• Generar un documento en el soporte más adecuado (pagina web, nota infor-
mativa en tablón de anuncios, etc.) con preguntas frecuentes (FAQ), en
donde los usuarios puedan aclarar las dudas más habituales y puedan solici-
tar ayuda o soporte técnico en el uso de la nueva versión.
• Se formará a los técnicos responsables de la explotación de nuevos modelos
de operación o de nuevas tecnologías si fuera necesario.
Evaluar resultados y Revisión postimplantación. Una vez implantada la entrega,

se debe realizar la revisión postimplantación (PIR) con los clientes y usuarios, para
garantizar que la entrega y los cambios que contiene funcionan a la perfección. Una
vez obtenida la aceptación por el área cliente y los usuarios, se procede al cierre de
la entrega y de las RFC que contiene.
La revisión postimplantación es ejecutada por la gestión de la entrega, y comuni-

cada a gestión del cambio.
En cambios importantes, se suele dejar un plazo de un par de semanas para realizar
el PIR.
UNE-ISO/IEC 20000-2
Se debería medir y analizar el número de El proceso de gestión del cambio debe-

incidentes relacionados con una entrega ría incluir una revisión post-implantación.
en el periodo inmediatamente posterior a
Las recomendaciones se deberían incluir
un despliegue para evaluar su impacto
en un plan de mejora del servicio.
en el negocio, en las operaciones y en
los recursos de personal de apoyo.

Es necesario elaborar informes que permitan evaluar el rendimiento del proceso de
la gestión de la entrega. Para que estos informes ofrezcan una información precisa
y de sencilla evaluación es necesario elaborar métricas de referencia que cubran
aspectos tales como:
• Número de entregas realizadas.
• Número de marchas atrás ejecutadas y razones de las mismas.
• Número de incidentes causados por las entregas, de forma directa o colateral.
• Porcentaje de cumplimiento de los plazos previstos para cada entrega.
• Recursos utilizados. Número medio de horas/hombre dedicadas por entrega.
• Corrección y alcance de la CMDB, la DSL y la DHS.
• Información relacionada con versiones ilegales de software.
• Adecuado registro de las nuevas versiones en la CMDB.
• Incidentes provocados por uso incorrecto (formación inadecuada) de la
nueva versión por parte de los usuarios.
• Incidentes provocados por la operación incorrecta (formación inadecuada)
de la nueva versión y componentes por parte de los técnicos y responsables
de la operación.
• Desviación de la disponibilidad del servicio respecto al nivel planificado

(PSA). Esta desviación se mide tanto durante el proceso de despliegue como
después de la implantación.
• Satisfacción del cliente y usuario final con el proceso de la entrega del servicio.
En la figura 10.1.8 se muestra un resumen de los indicadores más relevantes para

este proceso seleccionados por un grupo de trabajo de itSMF España.
de itSMF España
Roles participantes en la gestión de la entrega

Los roles involucrados en la gestión de la entrega se estructuran en los roles pro-
pios del proceso y los roles ajenos al proceso.
• El gestor de la entrega (gestor del proceso o process manager), que es el res-
ponsable del día a día de la actividad del proceso. En este caso realiza la pla-
nificación de las entregas, supervisa las pruebas, solicita a la gestión del cam-
bio la autorización para implantar, etc.
• Los administradores o el personal de soporte al proceso, ayuda al gestor de
la entrega en el control de toda la actividad.
• Los especialistas en tecnologías, aplicaciones y formación, que realizan las

pruebas técnicas y funcionales, realizan la implantación y despliegue y reali-
zan la formación a los usuarios sobre los nuevos servicios.
• El propietario del modelo SGSTI actúa como propietario del proceso (pro-
cess owner). Define las actividades del proceso y se encarga de la mejora con-
tinua del mismo. Todo ello, de una forma integrada con el modelo de ges-
tión del proveedor TI incorporado en el SGSTI.
• El responsable de la gestión del cambio, que debe autorizar el inicio de las
pruebas e integración, la implantación en producción y el cierre de la entrega.
Los roles de mayor relevancia que participan en el proceso de gestión de la entrega

Resumen
El proceso de la gestión de la entrega proporciona control sobre la implementación
de los cambios, garantiza la calidad de lo construido y vela por minimizar el
impacto de las paradas en los entornos productivos. Junto con la gestión del inci-
dente, es uno de los procesos que más recursos consume de TI y más tensión
genera, por lo que deberá tenerse en cuenta en su primera implementación y en el
ciclo de mejora continua.
Por tanto, la gestión de la entrega:
• Proporciona confianza, en cuanto a robustez de la solución, al haber sido
certificada en los entornos y modelos de pruebas.
• Aporta eficiencia a la organización, al ofrecer una sistemática para el desplie-
gue de componentes, optimizado y monitorizado, que reduce el tiempo nece-
sario para realizar estas tareas. Automatizando aquellas que sean repetitivas.
• Pone orden manteniendo un listado de cambios planificados (FSC).
• Ejerce control sobre los servicios, al disponer de una sistemática para instalar
cualquier versión de estos.
• Garantiza, de forma coordinada con el proceso de la gestión del cambio, la
disponibilidad y estabilidad de la operación diaria de los servicios con una
Roles del proceso
Responsable de la
SGSTI
Gestor de Administrador y
la entrega soporte del proceso
de entrega
Propietario del
modelo (SGSTI)
Especialista Especialista Especialista

en tecnologías en aplicaciones en formación
Gestor del cambio
Figura 10.1.9. Roles del proceso de gestión de la entrega
política de entregas pactadas, con fechas para los pasos a explotación acorda-
dos. Esto permite hacer un calendario junto con los responsables de los servi-
cios, que posibilita el no hacer coincidir en el tiempo despliegues y puntas
de negocio, o fechas críticas para la correcta prestación del servicio.
• Prevé con anterioridad la necesidad de recursos para el proceso, lo que per-
mitirá una correcta planificación de las personas y los componentes.
• Controla a los proveedores en cuanto a la validez de sus entregas.
• Garantiza de que la CMDB esta correctamente actualizada.
• Controla el software instalado en producción, su parametrización y documen-
tación, a través de una DSL actualizada. Esto incluye no sólo sistemas ope-
rativos y aplicaciones sino también controladores de dispositivos y documen-
tación asociada.
• Control de forma rigurosa y eficiente del almacén de hardware (DHS). Los

activos almacenados deben incorporarse a la CMDB en el caso de que los CI
correspondientes se hallen registrados en la misma (esto puede depender del
alcance y nivel de detalle de la CMDB).
Beneficios
Los principales beneficios aportados por el proceso de gestión de la entrega son los
siguientes:
• Los cambios en los servicios se realizan sin deterioro de la calidad de servicio.
• Las nuevas versiones cumplen los objetivos propuestos.
• Se reduce el número de incidentes por incompatibilidades con otro software
o hardware instalado.
• Se establece un orden lógico para el paso a producción, que permite la inte-
gración no traumática de las diferentes soluciones, evitando los incidentes
por efectos colaterales en producción.
• El proceso de pruebas asociado, no sólo permite asegurar la calidad del software
y hardware que se va a instalar, sino que también permite conocer la opinión de
los usuarios sobre la funcionalidad y usabilidad de las nuevas versiones.
• También permite detectar posibles problemas de capacidad, en las pruebas
realizadas, y actuar con la gestión de la capacidad, para garantizar las necesi-
dades en producción.
• El correcto mantenimiento de la DSL impide que se pierdan las valiosas
copias de los archivos fuente.
• Se reduce el número de copias de software ilegales.
• Control centralizado del software y hardware desplegado.
• Se garantiza la existencia de un plan de marcha atrás a un punto estable, que
garantiza la posibilidad de continuidad de la explotación, todos los despliegues
son controlados en cuanto un nivel de impacto y riesgo sobre la producción.
• Protección contra virus y problemas asociados a versiones de software incon-
troladas.
• Se garantiza la existencia de los procedimientos de gestión y monitorización,
que permiten la correcta operatividad en producción, del software y hardware
desplegado.
• El cumplimiento de los requisitos de continuidad acordados, y prueba de su

correcto funcionamiento.
• Reducción del tiempo de puesta en producción.
• ¿Cómo encaja la metodología de pruebas en el proceso de entrega?
• El equipo de desarrollo de software, ¿qué papel juega en este pro-
ceso?
• Cite dos mejores prácticas en su organización relativas al proceso de
entrega.
2
11
Capítulo 11
La certificación de la
gestión del servicio de TI
conforme a ISO/IEC 20000
11.1. La primera certificación conforme a ISO/IEC 20000
11.2. Evidencias y registros importantes en una certificación


11. La certificación de la gestión del servicio de TI conforme a ISO/IEC 20000 735
El presente capítulo introduce los aspectos prácticos sobre el conjunto de activida-

des necesarias para obtener la certificación del cumplimiento de los requisitos de
ISO/IEC 20000-1.
En primer lugar, es importante resaltar que la certificación no debería ser un fin en
sí misma, sino más bien un medio. Es un medio que aporta un reconocimiento por
una entidad ajena al proveedor de TI, independiente, imparcial y con la credibili-
dad necesaria. El hecho de recorrer el camino de la certificación obliga a aplicar con
rigor los requisitos de la norma, por lo que también se conseguirá una mejora sig-
nificativa en la prestación de los servicios.
La certificación declara públicamente a las partes interesadas (organización, clien-
tes, proveedores, competencia) y a toda la sociedad en general, que dicha organiza-
ción gestiona sus servicios mediante procesos de acuerdo a esta normativa.
Aunque la certificación frente a ISO/IEC 20000 es voluntaria, observamos cómo
el mercado está exigiéndola cada vez más, hoy se requiere en los contratos a sumi-
nistradores de TI, pero en poco tiempo se irá extendiendo a los departamentos
internos. Además, la certificación de la gestión de los servicios de TI aporta una
herramienta de marketing, interna y externa, a las organizaciones que la han alcan-
zado.
A lo largo de este capítulo se explicará todo el recorrido necesario para certificarse
en ISO/IEC 20000, desde la solicitud inicial hasta la ejecución de la primera audi-
toría y en su caso la obtención de la certificación. La descripción del proceso se ha
realizado tomando como referencia los procedimientos del área de certificación de
AENOR, y aunque los conceptos son generalizables, algunas actividades pueden
variar en la certificación con otras entidades certificadoras.
Antes de iniciar la lectura del capítulo se recomienda revisar el apartado 1.3
“Entender los entornos de normalización y certificación” de este libro, pues pre-
sentan una visión bastante completa de los actores en este ámbito.
De forma complementaria, en el apartado 11.2 se proponen una serie de eviden-
cias esenciales obtenidas de la experiencia práctica de la certificación.
11. La certificación de la gestión del servicio de TI conforme a ISO/IEC 20000
11.1. La primera certificación conforme a ISO/IEC 20000 737
11.1. La primera certificación conforme

a ISO/IEC 20000
Figura 11.1.1. Etapas de un ciclo de certificación genérico
De forma paulatina, se observa que la alineación con ISO/IEC 20000 es cada vez
más un criterio empleado en la toma de decisiones relevantes en la contratación de
recursos de TI, dado que la aplicación de estas normas permite a cualquier provee-
dor de servicios de TI acreditar la calidad en la prestación de sus servicios. Esto
quiere decir que están alineados con el negocio, que se aplican criterios de eficien-
cia, que se reducen los riesgos de operación del servicio, que se satisfacen los requi-
sitos de sus clientes, que se vela por el cumplimiento de los suministradores, etc.
Para obtener la certificación ISO/IEC 20000 es necesario tener implementado el
sistema de gestión del servicio de TI (SGSTI) y también haber evolucionado en las
formas de trabajar para incorporar las prácticas y los requisitos de estas normas.
A partir de este momento, se está en disposición de cubrir una serie de etapas nece-
sarias para la obtención de la certificación.
El ciclo de certificación no es un recorrido lineal que empieza y termina. Más
bien, es parecido a un círculo de mejora, que comienza con la certificación inicial
y que culmina con el mantenimiento y mejora en la calidad de la gestión de los
servicios. Este aspecto es clave en ISO/IEC 20000-1. Por ello, en las normas se
ha definido un apartado específico denominado: “4. Planificación e implementa-

ción de la gestión del servicio” y el ciclo PDCA, que se convierten en los instru-
mentos fundamentales, tanto para la realización de las auditorías de seguimiento
anual, como en la renovación del certificado que se realiza cada 3 años.
Para iniciar este camino se necesitan dos actores: el solicitante (empresa u organi-
zación que aspira a conseguir la certificación conforme a la norma) y la entidad de
certificación (empresa u organización que tras la etapa de auditoría y evaluación de
conformidad de la organización solicitante respecto a la norma, concede o deniega
la certificación).
En la figura 11.1.2 se muestran las etapas del ciclo de certificación.
Las 9 etapas del ciclo de certificación se explican a continuación. Estas etapas están
en conformidad con ISO/IEC 17021.
1. Determinar el alcance de la certificación

Los proveedores de TI que aspiren a obtener la certificación ISO/IEC 20000-1
deben realizar, como primera tarea, la definición del alcance de su certificación.
En esta actividad, el proveedor debe concretar y delimitar el alcance o ámbito de
aplicación del sistema de gestión (SGSTI). Dicho alcance se refiere a los servicios
incluidos en su catálogo y que son gestionados de acuerdo al modelo. Asimismo,
es conveniente identificar el conjunto de clientes objeto de prestación de dichos
servicios. Finalmente, es necesario identificar las localizaciones de los centros y uni-
dades organizativas desde donde se prestan los servicios considerados.
El alcance viene a ser la foto que la organización de TI quiere mostrar al sector
de sus competencias y calidad en la gestión de servicios de TI. Para la realización de
esta foto por un tercero ajeno a la organización, de forma independiente e impar-
cial, es clave decidir qué elementos van a formar parte de esta imagen, de forma
que permita dejar muy claro, sin dudas ni ambigüedades, los servicios de TI, los
clientes y las ubicaciones, centros y organizaciones donde se prestan.
Determinar el alcance de la certificación es uno de los temas más difíciles de acor-
dar entre la entidad certificadora y el proveedor de TI. Es el primer tema a tratar
con el equipo auditor. Un alcance muy reducido permitirá obtener la certificación
con un esfuerzo reducido, mientras que un alcance que comprenda a toda la orga-
nización de TI requerirá un gran esfuerzo de transformación. Por ello, el interés de
los aspirantes a la certificación de limitar el alcance.
Parece claro que el alcance debe contemplar los 13 procesos tratados en la
norma, además, del sistema de gestión del servicio y del ciclo de mejora continua
1. Determinar alcance
2. Solicitud de certificación
3. Auditoría fase I:
Análisis de documentación
4. Auditoría fase I:
Visita previa
5. Auditoría fase II
La primera
certificación ¿Existen Sí
no conformidades?
Plan de acciones
correctivas
6. Evaluación y decisión
¿Cumple No Auditoría extraordinaria

requisitos? (a los 6 meses)
Sí
7. Emisión del certificado
8. Auditorías de seguimiento
Mantenimiento de (años 1 y 2)
la certificación
9. Auditoría de renovación Responsabilidad proveedor TI
(cada tercer año) Lidera el certificador
Fuente: AENOR.
Figura 11.1.2. Ciclo típico de certificación utilizado para ISO/IEC 20000-1

PDCA. Pero no está tan claro si se deben certificar todos los servicios, todas las
localizaciones, todos los clientes a la vez. De aquí, la importancia en consensuar el
alcance.
Es frecuente acometer el alcance completo en varias certificaciones sucesivas, más
pequeñas, más rápidas y con menos riesgo de fracaso. Es importante que los servi-
cios seleccionados para la certificación sean lo suficientemente representativos para
el proveedor de TI, ya sea por volumen de actividad, impacto en la cuenta de resul-
tados, etc.
Una vez identificados los servicios hay que determinar las ubicaciones en las que se
prestan. Es necesario identificar qué ubicaciones entrarán a formar parte de la cer-
tificación. En este punto, lo deseable es que las ubicaciones elegidas sean todas en
las que se prestan los servicios seleccionados y, en el caso de certificaciones con el
alcance reducido deben ser lo suficientemente representativas. Además, las exclu-
siones deben estar perfectamente justificadas.
Llegados a este punto es recomendable que el proveedor de TI realice una evalua-
ción de la situación actual del alcance definido para la certificación (véase la evalua-
ción o assessment descrito en el capítulo 4). De esta forma, podrá determinar su
situación respecto a los requerimientos de la norma. En el caso de necesitar acome-
ter mejoras en el sistema de gestión del servicio de TI, evaluar su viabilidad, y
tomar la decisión de si se inicia el proceso de certificación.
Hasta este momento el proveedor de TI no ha tenido contacto con el equipo de
auditoría de la certificación, por lo que la definición del alcance y la evaluación rea-
lizados son internas y no están validadas por el certificador.
2. Solicitud de certificación
El siguiente paso cubre la confección del “formulario de solicitud de certificación”,
que la entidad de certificación remite al proveedor de TI previa solicitud.
En la solicitud se incluye información, como por ejemplo, el alcance de la certifica-
ción, contactos, direcciones, número de personas de la organización, número de
emplazamientos, etc. (véase la figura 11.1.3).
Esta información es importante, ya que proporciona una idea de la dimensión del
sistema de gestión de servicios que se pretende certificar y que será una de las varia-
bles que se deben tener en cuenta a la hora de planificar la auditoría. Esta planifica-
ción determina el volumen de las actividades que se van a realizar y la estimación
de carga de trabajo, que dará como resultado una oferta de la entidad de certifica-
ción con un presupuesto.
Fuente: AENOR.
Figura 11.1.3. Ejemplo de una solicitud de certificación

Tras la aceptación de la oferta por el proveedor de TI, la entidad de certificación le

asigna un número de expediente que le identificará durante toda la vida del certifi-
cado. El certificador designa un técnico experto en el sector y que se podría definir
como el gestor del expediente. A esta figura se la denomina TRE (Técnico Respon-
sable del Expediente).
El TRE será quien, partiendo de la información recibida y, junto con el responsa-
ble definido por la organización de TI, planificará la certificación: visitas, horarios,
servicios, emplazamientos, etc. También es el responsable del equipo auditor.
Para cada una de las visitas, y de forma previa, se envía al proveedor de TI, por
parte del equipo auditor, un plan de auditoría en el que, como mínimo, se reflejará
la siguiente información:
• Composición del equipo auditor.
• Representante de la organización.
• Centros que se deben visitar.
• Actividades objeto de la visita.
• Fecha, horario y planificación detallada.
3. Auditoría fase I: Análisis de documentación

Esta actividad constituye el primer contacto operativo de la auditoría. Su objetivo es el
estudio de la documentación del sistema de gestión de TI (SGSTI). La finalidad de esta
actividad es determinar si la documentación del sistema se corresponde con los requisi-
tos de gestión del servicio establecidos, ya sean por la propia norma de referencia, los de
sus clientes, los legales y reglamentarios, o los propios del sistema de gestión.
En esta actividad se revisan los documentos principales del SGSTI (véase el capí-
tulo 3):
• Manual del SGSTI.
• Manual de procesos y procedimientos del SGSTI.
• Registros de los procesos.
• La gestión del propio SGSTI: el manual sobre la propia organización del sis-
tema de gestión.
El resultado de esta actividad quedará reflejado en un informe con las observacio-

nes detectadas (IOM, Informe de Observaciones al Manual). Estas consideraciones
serán tenidas en cuenta por el equipo auditor en la siguiente actividad, que se deno-
mina visita previa.
Este análisis se puede realizar tanto en las instalaciones de la organización de TI,
como en las instalaciones de la entidad certificadora. En ocasiones se realiza
de forma conjunta con la visita previa que se detalla a continuación. El análisis de
documentación y la visita previa forman parte de la auditoría fase I.
4. Auditoría fase I: Visita previa

El siguiente paso es la visita previa (VPR, Visita Previa). En ella, los auditores visi-
tan la organización con los siguientes objetivos principales:
• Revisar y analizar el alcance de la certificación.
• Comprobar el grado de implantación y adecuación del SGSTI.
• Revisar el plan de auditoría fase I y aclarar las dudas que se puedan tener
sobre el procedimiento de certificación.
• Coordinar y cerrar el plan de la siguiente fase, la “auditoría fase II”.
En relación a la revisión y análisis del alcance de la certificación, es importante des-

tacar que el papel de la entidad de certificación consiste en garantizar la consisten-
cia necesaria y asegurar que las organizaciones no excluyen del alcance ningún
elemento (ubicaciones físicas de la empresa solicitante, servicios prestados, infraes-
tructura, clientes, recursos) que deba ser incluido.
La entidad de certificación comprobará, por tanto, que el alcance solicitado sea lo
suficientemente representativo del negocio, refleje correctamente sus actividades y
que los planes de mejora se extiendan a los límites de sus actividades, según lo defi-
nido en la documentación del sistema de gestión.
La auditoría fase I es una versión reducida de la siguiente actividad. La auditoría
fase II, revisa el grado de implantación y funcionamiento del sistema de gestión del
proveedor de servicios de TI contenido en el manual de gestión SGSTI y de sus
procesos.
En esta visita, aunque sí se revisa el funcionamiento de los procesos, no se suelen
pedir evidencias formales de sus resultados. Cubre entre el 30% y el 50% del total
del trabajo que se debe realizar.
Como conclusión a la visita previa, se emite un informe con las observaciones
detectadas respecto a la implantación del SGSTI. Estas observaciones y no confor-
midades serán tenidas en cuenta en la auditoría fase II.
Resulta interesante destacar que la auditoría fase I es sumamente útil, y podemos

considerarla como una “buena práctica” que contribuye de forma importante al
éxito del proceso de certificación.
El siguiente paso que se debe realizar es la auditoría fase II. Antes de realizarla,
debería transcurrir el tiempo suficiente que permita a la organización de TI la
corrección de aquellos aspectos más significativos detectados en la auditoría fase I.
5. Auditoría fase II
La auditoría fase II es la actividad clave en el proceso de certificación. En ella el
equipo auditor evalúa al completo el sistema de gestión de servicios de TI
(SGSTI). Analiza su conformidad con relación a los requisitos de la norma y com-
prueba su implantación y funcionamiento operativo.
Para ello, la entidad certificadora confecciona un plan de auditoría específico para
el cliente (véase la figura 11.1.4).
La auditoría fase II comienza con una reunión en la que se presenta el plan de tra-
bajo de la auditoría y se concretan las entrevistas con las personas de las áreas que
serán objeto de la visita. Esta etapa, dependiendo del alcance de la certificación
acordado, puede durar entre 3 y 6 jornadas.
Para cada uno de los servicios y centros incluidos en el alcance de la certificación, se
revisará el cumplimiento del manual de gestión de servicios y su adecuación a la
norma objeto de certificación. Para realizar esta labor, el equipo auditor revisará el
cumplimiento de la norma mediante comprobaciones in situ y evidencias formales
de su cumplimiento.
El resultado de la auditoría fase II se plasma en un informe, en cuyo contenido se
reflejarán las “no conformidades” o incumplimientos detectados por el equipo
auditor. Dichos incumplimientos estarán contrastados frente a los requisitos espe-
cificados por la norma, los legales o reglamentarios, los de los clientes de la organi-
zación o los propios del SGSTI.
El informe será entregado y comentado en la reunión final de auditoría.
Plan de acciones correctivas. En el caso que el informe de la auditoría refleje no
conformidades, el proveedor de TI debe confeccionar un documento específico: el
Plan de Acciones Correctivas (PAC).
Para ello, la organización dispone de un plazo de tiempo establecido para presentar
a la entidad de certificación el plan de acciones correctivas dirigido a subsanar las no
conformidades detectadas en la auditoría. En dicho plan se debe incluir un análisis
Plan de la auditoria fase II
• Nombre de la empresa.
• Domicilio.
• Alcance de la auditoría.
• Normas de referencia que aplican.
• Composición del equipo auditor.
• Programa de trabajo, detallando:
– Reunión inicial:
• Fechas y horarios.
• Auditores y asistentes.
• Agenda.
– Reuniones de auditoria:
• Servicios de TI y apartados de la
norma a auditar en cada reunión.
– Reunión final:
Fuente: AENOR.
Figura 11.1.4. Contenido tipo del plan para la auditoría fase II
de las causas que motivaron cada uno de los incumplimientos y, también, deben
quedar reflejados los responsables de la implantación de dichas acciones.
Una vez emitido el plan de acciones correctivas, puede ocurrir que se necesiten
aclaraciones relacionadas con las acciones enviadas, por lo que podría ser necesario
efectuar “ampliaciones del PAC”.
6. Evaluación y decisión
Cuando se ha cerrado el plan de acciones correctivas, el responsable de la auditoría
envía un informe a la entidad de certificación con una recomendación sobre la con-
veniencia de conceder, o no, la certificación al proveedor de TI solicitante.
En este punto, el comité de certificación (de la entidad de certificación) decide otor-

gar o no la certificación, basándose en el análisis del informe de la auditoría fase II y
en el plan de acciones correctivas, si se cumplen los requisitos de certificación.
Auditoría extraordinaria. En el caso que no se cumplan los requisitos de certifica-
ción, sería necesaria una visita adicional, llamada auditoría extraordinaria, que nor-
malmente se planifica a seis meses después de la auditoría fase II. Su objetivo es com-
probar la implantación de los incumplimientos que motivaron la visita extraordinaria.
7. Emisión del certificado

Si la decisión es positiva, la entidad certificadora procederá a la concesión del certi-
ficado ISO/IEC 20000-1, que entra en la categoría de certificado de registro de
empresa. Además, gestionará el Certificado IQNet (véase la figura 11.1.5).
El certificado de IQNet, le otorga al certificado de registro de empresa un carác-
ter internacional. Mediante este certificado adicional se consigue el reconoci-
miento internacional de los certificados concedidos en un país.
8. Auditorías de seguimiento
El certificado tiene una validez de tres años. A lo largo de los cuales la entidad cer-
tificadora realizará auditorías de seguimiento para comprobar que el sistema de
gestión continúa cumpliendo con los requisitos indicados en la norma y que cada
año el SGSTI se mantiene y mejora dentro del ciclo de mejora continua.
De este modo, transcurrido un año desde la certificación, se planifica la primera
auditoría de seguimiento (AS1) y, al año de ésta, se planifica la segunda auditoría
de seguimiento (AS2).
9. Auditoría de renovación
Una vez cumplidos los 3 años de validez, la certificación expira (caduca) y se debe
realizar una auditoría de renovación de la certificación (muy similar a la auditoría
de certificación fase II).
Tanto en las auditorías de seguimiento como en la de renovación, también se emite
un informe en el que quedan reflejadas las no conformidades o incumplimientos. El
proceso de respuesta a las no conformidades mediante el plan de acciones correctivas
(PAC) se repite, así como, el de evaluación y decisión.
Fuente: AENOR.
Figura 11.1.5. Ejemplo de certificado de Registro de Empresa ISO/IEC 20000
Si se siguen cumpliendo con los requisitos de certificación, se otorga el manteni-

miento (en el caso de auditorías de seguimiento) o la renovación (en el caso de
auditoría de renovación) del certificado. Al igual que en la auditoría fase II, tam-
bién podría darse el caso que se necesitase de una auditoría extraordinaria para
estos mantenimientos o renovaciones.
Resumen del ciclo de certificación

El proceso de certificación se puede esquematizar en los siguientes puntos:
1. Determinar el alcance de la certificación. Definir los servicios y centros
sobre los que se aplicará el procedimiento de certificación. En este punto, es
importante que la organización de TI solicitante realice un análisis de su

situación actual respecto a ISO/IEC 20000-1 para determinar el momento
adecuado de realizar la solicitud.
2. Solicitud de certificación. La empresa que aspira a obtener la certificación
realiza una solicitud de certificación a una entidad acreditada, y esta entidad
confecciona una propuesta que envía al proveedor de TI solicitante para su
estudio, aprobación y contratación.
3. Auditoría fase I: Análisis de documentación. La entidad de certificación
estudia la documentación del sistema de gestión de la empresa solicitante.
4. Auditoría fase I: Visita previa. La entidad de certificación realiza su tra-
bajo in-situ en el proveedor solicitante, con el objetivo de conocer la empresa
y evaluar la idoneidad del alcance solicitado de la certificación; y analizar
cómo está implantado el sistema de gestión SGSTI. Esta etapa es el punto
idóneo para resolver cualquier duda que surja por parte del proveedor de TI
solicitante o de la entidad de certificación. Realmente la experiencia indica
que la visita previa es una “activad clave para el éxito del procedimiento de
certificación”.
La entidad de certificación prepara el plan de auditoría, que debe incluir pla-
nificación de fechas y miembros del equipo de auditoría, contenidos a audi-
tar, etc., que se entrega al proveedor de TI solicitante para su revisión y apro-
bación.
5. Auditoría fase II. La entidad de certificación lleva a cabo la auditoría fase II
de certificación, sobre los servicios e instalaciones acordadas, del proveedor
solicitante. En el caso que existan no conformidades se emite un informe de
no conformidades, señalando las no conformidades o desviaciones detectadas.
Si es necesario, la organización solicitante debe realizar un plan de acciones
correctivas, que se pone en práctica para corregir las desviaciones detectadas,
y debe evidenciar la corrección de dichas desviaciones ante la entidad de cer-
tificación.
6. Evaluación y decisión. La entidad de certificación, mediante un comité de
decisión, analiza y valora dichas acciones y en caso de valoración positiva
concede el certificado.
7. Emisión del certificado. Con la decisión positiva se emite el certificado, con
el alcance establecido, a favor del proveedor de TI solicitante.
8. Auditorías de seguimiento. La entidad de certificación, anualmente, realiza
auditorías de seguimiento del sistema de gestión certificado (AS1 y AS2),
normalmente seleccionando partes de dicho sistema y no la totalidad del

mismo, para comprobar su efectividad, levantando, en caso de encontrar
incumplimientos, las no conformidades necesarias que la organización ya
acreditada debe resolver mediante un nuevo plan de acciones correctivas.
9. Auditoría de renovación. Pasados tres años desde la consecución del certifi-
cado, la entidad de certificación realiza una nueva auditoría, en este caso muy
parecida a la auditoría fase II, con el objetivo de prorrogar o cancelar la cer-
tificación concedida.
11.2. Evidencias y registros importantes en una certificación 751
11.2. Evidencias y registros importantes

en una certificación
Figura 11.2.1. Esquema general de los registros y evidencias
En el presente apartado se recopilan los registros y evidencias considerados más

importantes que será necesario ir recopilando, como consecuencia de la implanta-
ción de cada uno de los procesos exigidos por la norma.
En el capítulo 3 se aclaraba la diferencia entre estos conceptos de registro y evi-
dencia:
“Un registro es el resultado tangible de la actividad de TI y de los procesos, por
ejemplo: el incidente registrado en la herramienta de gestión del incidente, una
encuesta de satisfacción del cliente, una solicitud de cambio (RFC), unas medidas,
un informe del servicio, un SLA, un elemento en la base de datos de configuración,
etc. También son registros la documentación del sistema y sus evoluciones.
Una aplicación importante de los registros es la de proporcionar evidencias de
la conformidad del proveedor de TI con los requisitos de estas normas.
Las evidencias son cualquier documento o prueba que proporcione una demos-
tración objetiva del cumplimiento de las normas por el proveedor de TI. Las
evidencias se obtienen de los registros y de cualquier otra forma que permita

probar que se cumplen los requisitos (por ejemplo, un documento, una com-
probación, etc.).”
Por tanto, las evidencias son el medio por el que se demuestra al resto de la organi-
zación, a los clientes y a los auditores, el cumplimiento de los requisitos expresados
en la parte 1 de las normas ISO/IEC 20000. Las evidencias también demuestran
que se siguen los procesos y procedimientos que integran el sistema de gestión
de TI. El objetivo es poder mostrar de manera fehaciente la orientación al servicio del
proveedor de TI, así como, el alineamiento con el negocio.
La generación de evidencias no debe tener como fin “satisfacer al auditor”. No se
debe olvidar que la auditoría será mucho más fácil de superar si el sistema de ges-
tión está adecuadamente implantado y afianzado. Cuando las evidencias son pro-
porcionadas por el trabajo diario surgen de forma natural, así, nadie debería estar
pensando en temas como:
“…ahora toca preparar el informe de seguimiento del proceso porque me lo piden para
la auditoría”,
sino que más bien pensaría en:

“…tengo que preparar el informe de seguimiento del proceso para presentarlo en el
comité de gestión del servicio de TI e informar de cómo está funcionando mi proceso y
cómo podemos mejorar su desempeño”.
En la primera situación, la evidencia se percibe como una carga (más burocracia),

mientras que en el segundo, se ve como un instrumento que ayuda en el trabajo. Si
el sistema de gestión se ha planteado con sentido común, pensando en las necesi-
dades de la organización, en el negocio y en los clientes, en ningún caso deberían
acudir a nuestra cabeza planteamientos similares al primer caso y, si es así, sería
mejor dejar de generar ese informe y buscar otra evidencia con verdadera utilidad.
Las evidencias muestran cómo los procesos generan resultados que al final, directa
o indirectamente, son necesarios para poder prestar el servicio de TI a los clientes.
Mediante las evidencias se demuestra que los procesos están implantados, se ejecu-
tan según lo previsto y los resultados son los adecuados. Es decir, las evidencias tie-
nen un valor intrínseco para los procesos y ayudan a satisfacer las necesidades de
los clientes.
En este capítulo se proponen una serie de evidencias obtenidas de la experiencia
práctica de la certificación, que se entienden como las más comunes para demos-
trar el cumplimiento de los requisitos de la Norma ISO/IEC 20000-1. No quiere
decir que sea un listado exhaustivo o excluyente, pero sí útil, y en algunos casos
suficiente para determinadas organizaciones.
Por tanto, esta relación no se puede considerar como obligatoria, simplemente pre-
tende ser una ayuda. Será el auditor, en cada caso, el que determine cuáles son las
evidencias más adecuadas para cada situación. Dado que las evidencias son el modo
por el que la organización muestra que tiene control sobre cada uno de los proce-
sos que integran el sistema de gestión, habrá que adaptar el número y el tipo de
evidencias que se van a recopilar a la realidad de cada organización y cómo éstas
se asocian a cada proceso.
A continuación se detallan, para cada uno de los procesos definidos en la Norma
ISO/IEC 20000-1 las evidencias asociadas.
Evidencias para “3. Requisitos de un sistema de gestión”

Evidencias para “3.1. Responsabilidades de la dirección”:
• Acta de revisión del sistema por la dirección. Evidencia el compromiso de
la dirección con el sistema de gestión al comprobar el grado de despliegue,
así como las necesidades y propuestas de mejora. Al menos se realizará una
reunión al año y siempre que a juicio del responsable del sistema de gestión
o de la dirección se estime necesaria.
• Planificación y seguimiento de objetivos. Expresa el compromiso de mejora
de la dirección. Los objetivos deben ser realistas pero retadores, cuantificables
y medibles. Es muy recomendable su desglose en acciones concretas que per-
mitan su ejecución, así como asignar responsables de su consecución.
Evidencias para “3.2. Requisitos de la documentación”:

• Listado de documentación del SGSTI. Contiene información sobre la ela-
boración, aprobación, mantenimiento, archivo y destrucción de la documen-
tación (incluye evidencias del SGSTI).
Evidencias para “3.3. Competencia, concienciación y formación”:

• Responsables de los procesos, del SGSTI y de la gestión de los servi-
cios. Organigrama, definición de los puestos y designación de las personas a
los roles principales necesarios.
• Currículum Vítae (CV). Registros de la educación, formación, habilida-
des y experiencia de empleados incluidos dentro del alcance. Currículum
firmado o declaración de que la información que en él se contiene es

cierta.
• Plan de formación. Documento con el plan, que debe contener actividades
específicas de formación en la gestión del servicio de TI específicas de estas
normas. Formación en ITIL e ISO/IEC 20000. Con cursos en varios nive-
les, de fundamentos para la mayoría de la organización de TI, de especialista
para los responsables de los procesos y de Service Manager para los gestores
de los servicios y para el responsable del SGSTI.
• Cuestionario de evaluación de la acción formativa. Cumplimentado por
parte de los asistentes a la acción de formación.
• Certificaciones profesionales. Certificaciones en ITIL e ISO/IEC 20000
acordes con las funciones que desempeñen los profesionales.
• Informe de evaluación de la eficacia de la formación. Cumplimentado
por la persona de la que dependen los asistentes a la formación indicando
cómo la formación recibida ha ayudado a los asistentes a mejorar el desem-
peño de su trabajo. Certificaciones obtenidas.
Evidencias relacionadas con el reclutamiento y selección de personal. Aquí pue-

den englobarse desde planes para la provisión de puestos de trabajo, a solicitudes de
incorporación de personal, o los CV recopilados para un proceso en concreto.
Evidencias para “4. Planificación e implementación de la

gestión del servicio”
Evidencias para “4.1. Planificación de la gestión del servicio (plan)”. La evi-
dencia de su cumplimiento es el propio manual de gestión del SGSTI. Además, el
alcance y el catálogo de servicios vigente.
Evidencias para “4.2. Implementación de la gestión del servicio y la provisión
de los servicios (hacer)”. La evidencia de su cumplimiento es el manual de ges-
tión del SGSTI.
Evidencias para “4.3. Monitorización, medición y revisión”:
• Informe de no conformidad.
• Plan de acciones correctivas.
• Plan anual de auditorías internas. Recoge la planificación de auditorías
internas que se deben realizar. El único requisito, es que en el plazo de un
año se haya auditado todo el sistema de gestión, siempre antes de la audito-

ría de certificación. Estas auditorías pueden ser realizadas por auditores que
pertenezcan a la compañía o, en su defecto, por un tercero independiente.
En cualquier caso debe respetarse el principio: “No tener responsabilidad
directa sobre el trabajo que se va a auditar”.
• Informe de auditoría interna.
• Ficha de indicador. Proporciona información relativa al proceso, la descrip-
ción del indicador, el tipo de análisis que se debe realizar, el límite admisible, el
responsable del indicador, la frecuencia del análisis, la recogida de resultados.
• Cuadro de seguimiento del sistema de gestión. Recopila todos los indica-
dores, agrupados por procesos y en él se van reflejando los resultados de cada
uno de los indicadores, según la periodicidad establecida. Proporciona una
“fotografía” del desempeño y eficacia del sistema de gestión. Habitualmente
es mantenido por el responsable del sistema. Estos indicadores deben tener
un valor objetivo a alcanzar o un umbral de control.
• Cuadro de gestión de la mejora. Al igual que ocurre con los indicadores,
consolida todas las propuestas de mejora realizadas por cualquier actor del
sistema de gestión, una vez que han sido aprobadas por el responsable del
sistema o la dirección (según proceda). Facilita el seguimiento de las mejoras
y su gestión.
Evidencias para “5. Planificación e implementación de

nuevos servicios o de servicios modificados”
• Requisitos de nivel de servicio (SLR). Documento que describe de forma
detallada las necesidades del cliente.
• Documento de concepto (especificaciones del servicio SLS). Documento
que describe la relación entre la funcionalidad requerida por el cliente y la
tecnología empleada para implementarla.
• Plan de calidad del servicio. Documento donde la organización TI especi-
fica la forma en la que será entregado un servicio. Es el plan de proyecto de
creación del servicio.
• SLA asociados al servicio. Documentos que recogen los compromisos
acordados entre el cliente y la organización TI, para la provisión del servicio
requerido.
• Documentación del servicio (técnica, comercial, económica…).
Evidencias para “6. Procesos de provisión de servicio”

Evidencias para “6.1. Gestión de nivel de servicio”:
• Catálogo de servicios. Documento que elabora la organización TI para
informar a clientes y usuarios.
• Catálogo de SLA.
• Acuerdos de nivel operativo (OLA). Documentos que formaliza acuerdos
de colaboración entre departamentos internos de la organización TI para la
provisión y entrega de un servicio.
• Contratos de soporte (UC). Documentos contractuales entre la organiza-
ción TI y los proveedores externos de servicios.
Evidencias para “6.2. Generación de informes del servicio”:

• Informes de servicio. Informes de cumplimiento de SLA, informes de inci-
dentes, informes de disponibilidad, informes de capacidad, etc.
Evidencias para “6.3. Gestión de la continuidad y disponibilidad del servicio”:

• Plan de disponibilidad. Recoge los elementos de la infraestructura de TI
que deben ser monitorizados para medir la disponibilidad, comparando los
valores obtenidos con los de referencia. Sirve como base para determinar el
cumplimiento de los niveles de servicio en los SLA.
• Informes de disponibilidad. Informes periódicos que muestran el cumpli-
miento de los niveles de disponibilidad acordados.
• Documentos de requisitos de nivel de servicio (SLR). Deben recoger los
requisitos de disponibilidad del servicio demandados por los clientes.
• Plan de continuidad de TI. Identifica los activos del sistema de gestión de
servicios de TI, las situaciones de contingencia que pueden producirse, así como,
la probabilidad de que éstas se produzcan. Muestra cómo cada una de estas
situaciones de contingencia pueden afectar a los activos; por tanto, proporciona
información de cómo afectan las contingencias a los servicios prestados.
Proporciona información sobre los siguientes aspectos:
– Objetivo y alcance del plan de continuidad.
– Descripción de la situación a controlar (información sobre el suceso y los
parámetros que se quieren mantener).
– Suceso.
– Riesgo a controlar y nivel.

– Activos que intervienen.
– Nivel de servicio exigido.
– Tiempos para cada respuesta.
– Criterio/s disparador (a partir del cual se activa el plan de continuidad).
– Plan de respuesta.
– Plan de respaldo.
– Plan de recuperación.
– Plan de análisis y mejora.
– Plan de prueba.
• Plan de pruebas de continuidad. Identifica el tipo de pruebas a realizar

para verificar la adecuación de los planes de continuidad.
• Informes de los resultados de las pruebas.
Evidencias para “6.4. Presupuestar y contabilizar servicios TI”:

• Presupuesto.
• Informes de ejecución del presupuesto.
• Informes de gestión del presupuesto, como resultado de la contabilización
y tratamiento de desviaciones del presupuesto.
Evidencias para “6.5. Gestión de la capacidad”:

• Plan de capacidad.
• Información de seguimiento de la capacidad. Base de datos de capacidad
y otras herramientas.
Evidencias para “6.6. Gestión de seguridad de la información”:

• Política de seguridad.
• Análisis de riesgos. Identifica los activos del SGSTI, necesarios para la pres-
tación de los servicios; asocia amenazas a los activos y determina su nivel de
riesgo. Muestra el riesgo que soporta la organización.
• Declaración de riesgos.
• Plan de tratamiento de riesgos de seguridad. Identifica los controles a

implantar para reducir el riesgo soportado de la organización.
• Registros de seguridad.
• Informes de seguridad.
Evidencias para “7. Procesos de relación”

Evidencias para “7.2. Gestión de relaciones con el negocio”:
Muestra los documentos que se generan en las distintas fases, desde la identifica-
ción de las necesidades del cliente hasta la prestación del servicio:
• Propuestas de servicio al cliente (SLR).
• Acuerdos de nivel de servicio firmados (SLA).
• Informes de servicio.
• Actas de seguimiento de clientes y resultados de encuestas de satisfacción.
Evidencias para “7.3. Gestión de suministradores”:

• Política de gestión de suministradores y estrategia de sourcing.
• Base de datos de suministradores y contratos (SCD). Conteniendo una
relación de los servicios contratados, empresas y responsables.
• Documentación contractual del servicio (UC). Contrato, RFP, pedido o
documento similar.
• Resúmenes de los servicios contratados a los suministradores.
• Informes del servicio de los suministradores.
• Propuesta de resolución anticipada del servicio.
• Actas de reuniones con suministradores.
Evidencias para “8. Procesos de resolución”

Evidencias para “8.2. Gestión del incidente”. Establecen los soportes en los que
registrar incidentes así como la explotación de dichos soportes.
• Base de datos de incidentes. Registro adecuado de la información. Histo-
rial de resolución de los incidentes graves.
• Relación de soluciones temporales implantadas (workarounds).

• Informes de incidentes. Cumplimiento de los niveles de servicio (atención
y resolución) pactados con el negocio.
• Herramienta para la monitorización y gestión de eventos. Herramienta
que permite detectar incidentes de manera automática, integrada con la base
de datos de incidentes.
• Mejoras y formación de la primera línea de atención. Identificación de la
tasa de incidentes resueltos en primera línea, registros de estos incidentes.
Evidencias para “8.3. Gestión del problema”. Establece los soportes en los que
registrar problemas, además de la documentación asociada al mismo.
• BD de problemas. Recoge los problemas identificados, proporcionando
información del estado en que se encuentran.
• Documentación de la resolución asociada al problema. Accesible por las
líneas de soporte.
• Comunicación entre la gestión del incidente y del problema.
Evidencias para “9. Procesos de control”

Evidencias para “9.1. Gestión de la configuración”. Incluye las evidencias que
se generan a la hora de planificar la configuración y la definición de la estructura de
la CMDB. La relación entre los elementos de configuración y su uso. Información
de auditoría de la CMDB.
• Plan de gestión de la configuración, elaborado antes de crearse por pri-
mera vez la CMDB, o ante un cambio significativo en la misma. Contiene
información relativa a:
– Propósito.
– Objetivo.
– Alcance.
– Planificación de actividades.
– Organización.
– Herramientas de soporte.
– Análisis de la Información disponible y sus fuentes.
• Elementos de configuración (CI). Información correcta sobre los compo-

nentes de los servicios en la CMDB.
• Base de datos de gestión de la configuración (CMDB). Actualizada.
• Biblioteca de software definitivo (DSL). Actualizada.
• Informes de la gestión de la configuración.
• Resultados de auditorías de la configuración.
Evidencias para “9.2. Gestión del cambio”:

• Solicitudes de cambio (RFC). Debe poder diferenciarse qué RFC corres-
ponden a cambios urgentes frente al resto. Datos de las RFC correctamente
cumplimentados. Existencia de planes de marcha atrás.
• Informes de disponibilidad prevista (PSA).
• Informes de los resultados de las pruebas.
• Informes de intervenciones.
• Lista de cambios planificados (FSC).
• Informes de revisiones post implementación (PIR).
• Lista de notificación de intervención sin registrar.
• Actas del comité de cambios (CAB).
Evidencias para “10. Proceso de entrega de versiones”

Evidencias para “10.1. Proceso de gestión de la entrega”:
• Política de entregas.
• Hoja de control de entregas.
• Documentación técnica de las entregas.
• Planificación de las entregas. Proporciona, al menos, información relativa
a: tareas, responsables, fechas y entregables.
• Documentación de compras asociadas a la entrega.
• RFC aprobados asociados a las entregas. Las entregas deben ser controla-
das por el proceso de gestión del cambio.
• Actualización de la información en la DSL y CMDB por este proceso.
• Almacén definitivo de hardware (DHS). Existencia (si es necesario),

orden y etiquetado del almacén, y listado del control de su contenido.
• Realización del PIR de las entregas. Informes que recogen los resultados
de la entrega y los compara con los previstos. Al final permite concluir si la
entrega ha cubierto las expectativas generadas o no.
Bibliografía y referencias
Publicaciones sobre ISO/IEC 20000

• ISO 20000 Guía de Bolsillo (Spanish Version). Van Haren Publishing. ISBN:
9077212795.
• ISO/IEC 20000 Una introducción. Van Haren Publishing. ISBN: 978 90 8753
293 2.
• Implementing ISO/IEC 20000 Certification. The Roadmap. ITSM LIBRARY.
Van Haren Publishing. ISBN: 978 90 8753 082 2.
Publicaciones sobre ITIL v2

• Soporte de Servicio. OGC/HMSO. ISBN: 0 11 330981 3.
• Provisión de Servicio. OGC/HMSO. ISBN: 0 11 330983 X.
• Gestión de Servicios TI, basado en ITIL, una introducción (Spanish Version), Van
Haren Publishing. ISBN: 9077212183.
• Service Support. OGC/HMSO. ISBN: 0 11 330015 8.
• Service Delivery. OGC/HMSO. ISBN: 0 11 330017 4.
• ICT Infraestructure Management. OGC/HMSO. ISBN: 0 11 330865 5.
• Planning to Implement Service Management. OGC/HMSO. ISBN: 0 11 330877 9.
• Security Management. OGC/HMSO. ISBN: 0 11 330014 X.
• Software Asset Management. OGC/HMSO. ISBN: 0 11 330943 0.
• Application Management. OGC/HMSO. ISBN: 0 11 330866 3.
• Business Perspective. OGC/HMSO. ISBN: 0 11 330894 9.
Publicaciones sobre ITIL v3

• Introduction to ITIL 3 Service Lifecycle (English Version). OGC/HMSO. ISBN:
978 0 11 331061 6.
• Estrategia del Servicio. OGC. ISBN: 978 0 11 331158 3
• Diseño del Servicio. OGC. ISBN: 978 0 11 331226 9
• Transición del Servicio. OGC. ISBN: 978 0 11 331227 6
• Operación del Servicio. OGC. ISBN: 978 0 11 331150 7
• Mejora Continua del Servicio. OGC. ISBN: 978 0 11 331146 0
• Service Strategy. OGC/HMSO. ISBN: 978 0 11 331045 6.
• Service Design. OGC/HMSO. ISBN: 978 0 11 331047 0.
• Service Transition. OGC/HMSO. ISBN: 978 0 11 331048 7.
• Service Operation. OGC/HMSO. ISBN: 978 0 11 331046 3.
• Continual Service Improvement. OGC/HMSO. ISBN: 978 0 11 331049 4.
• Foundations of IT Service Management Based on ITIL V3. ITSM LIBRARY, Van
Haren Publishing. ISBN: 978 90 8753 057 0.
Otras publicaciones de interés

• IT Services Organisation. OGC/HMSO. ISBN: 0 11 330563 X.
• Planning and Control for IT Services. OGC/HMSO. ISBN: 0 11 330548 6.
• Quality Management for IT Services. OGC/HMSO. ISBN: 0 11 330555 9.
• IT Service Management Case Studies. OGC/HMSO. ISBN: 0 11 330676 8.
• Practices in Small IT Units. OGC/HMSO. ISBN: 0 11 330674 1.
• World Class IT Service Management Guide, ten Hagen & Stam. ISBN: 90 76383 46 4.
• The Guide to IT Service Management. Addison Wesley. ISBN: 0 20 173792 2.
• Frameworks for IT Management. Van Haren Publishing. ISBN: 9077212906.
• Metrics for IT Service Management. Van Haren Publishing. ISBN: 9077212698.
• Vivek Nanda: ISO 9001:2000 Lograr la conformidad y la mejora continua en
empresas de desarrollo de software. AENOR Ediciones. ISBN: 978 84 8143 416 3
Bibliografía y referencias 765
• Managing Successful Projects with PRINCE 2. The Stationary Office. ISBN: 0 11

330055 8.
• Process Innovation, Davenport. HBS. Boston, Massachusetts (EEUU), 1993.
ISBN: 0 87584 366 2.
Normativa
• UNE-ISO/IEC 20000-1:2007 Tecnología de la información. Gestión del servicio.
Parte 1: Especificaciones.
• UNE-ISO/IEC 20000-2:2007 Tecnología de la información. Gestión del servicio.
Parte 2: Código de buenas prácticas.
• UNE-ISO/IEC 17021:2006 Evaluación de la conformidad. Requisitos para los
organismos que realizan la auditoría y la certificación de sistemas de gestión.
• UNE-ISO 10005:2005 Sistemas de gestión de la calidad. Directrices para los planes
de la calidad.
• UNE-ISO/IEC 17799:2002 Tecnología de la información. Código de buenas prác-
ticas para la Gestión de la Seguridad de la Información.
• UNE-ISO/IEC 27001:2007 Tecnología de la información. Técnicas de seguridad.
Sistemas de Gestión de la Seguridad de la Información (SGSI). Requisitos.
• UNE 71044:1999 Tecnología de la información. Procesos del ciclo de vida del soft-
ware.
• UNE-EN ISO 9001:2008 Sistemas de gestión de la calidad. Requisitos.
• ISO/IEC 15288:2008 Systems and software engineering – System life cycle processes.
• ISO/IEC 15504-1:2004 Information technology – Process assessment – Part 1: Con-
cepts and vocabulary.
• ISO/IEC 15504-2:2003 Information technology – Process assessment – Part 2: Per-
forming an assessment.
• ISO/IEC 15504-3:2004 Information technology – Process assessment – Part 3:
Guidance on performing an assessment.
• ISO/IEC 15504-4:2004 Information technology – Process assessment – Part 4: Gui-
dance on use for process improvement and process capability determination.
• ISO/IEC 15504-5:2006 Information technology – Process Assessment – Part 5: An
exemplar Process Assessment Model.
• ISO/IEC TR 24774:2007 Software and systems engineering – Life cycle manage-

ment – Guidelines for process description.
Páginas web relacionadas

• AENOR:
http://www.aenor.es
• itSMF España:
http://www.itsmf.es
• itSMF International:
http://www.itsmf.org
• ISO (Organización Internacional de Normalización):
http://www.iso.net
• JTC1/SC7, subcomité perteneciente al comité técnico conjunto entre ISO e
IEC denominado JTC1 Tecnologías de la información, responsable del desarrollo
de las normas en el área de ingeniería del software y de los sistemas.
http://www.jtc1-sc7.org
• ISO 20000 Central (antes BS15000 Central)
http://20000.fwtk.org
• Portal de Soporte de ITIL e ISO 20000
http://www.15000.net
• EXIN (Certificación de profesionales en el ámbito de ISO 20000)
http://www.exin.org
• APMG (Certificación de profesionales en el ámbito de ISO 20000)
http://www.apmgroup.co.uk
• CMMI (Capability Maturity Model Integration)
http://www.sei.cmu.edu/cmmi/
• eSCM (eSourcing Capability Model)
http://itsqc.cmu.edu/models/index.asp
• COBIT (Control Objectives for Information and related Technology)
http://www.isaca.org/cobit.htm
• ISPL (Information Services Procurement Library)
http://projekte.fast.de/ISPL/
• eTOM (enhanced Telecom Operations Map)
http://www.tmforum.org
Términos y definiciones
Activo (Asset): Componente de un servicio de TI. Los activos pueden incluir per-
sonas, alojamiento, sistemas de ordenadores, redes, registros manuales, fax, etc.
Acuerdo de nivel de servicio (SLA): Un acuerdo escrito entre el proveedor de
servicio y cliente, que documenta niveles de servicio acordados por un servicio.
Acuerdos de colaboración operacional (OLA): Un acuerdo interno que da
cobertura a los servicios que soporta la organización de TI en su prestación
de servicios al cliente.
Análisis del impacto (impact analysis): La identificación de procesos de negocio
críticos, y el daño potencial o la pérdida que se puede causar a la organización
como resultado de una interrupción a estos procesos.
Análisis del riesgo: La identificación y evaluación del nivel (medida) de los ries-
gos, calculado a partir del valor de los activos y de los niveles evaluados de ame-
nazas y vulnerabilidades a los que están expuestos dichos activos.
Autoridad de cambios (Change authority): Grupo al que se delega autoridad de
aprobación de los cambios, por ejemplo por un comité de proyectos. Algunas
veces también se le conoce como comité de configuración.
Base de datos de la gestión de la configuración (CMDB): Una base de datos
que contiene todos los detalles relevantes de cada CI y detalles de relaciones
importantes entre los CI.
Biblioteca de software: Una colección controlada de CI software designada para
mantener juntos esos que tienen estados o géneros similares y segregados de
esos que no se parecen, para ayudar en desarrollo, operación y mantenimiento.
Biblioteca de software definitivo (DSL): Repositorio en el que se almacenan y
protegen las versiones autorizadas definitivas de todos los CI software. Se trata
de un espacio físico o de un repositorio de almacenamiento donde se sitúan las

copias “master” de las versiones de software.
Cambio (Change): Adición, modificación o eliminación referida a hardware,
redes, software, aplicaciones, entornos, sistemas, implementaciones o documen-
tación relacionada, previamente aprobados, de apoyo o base.
Catálogo de servicios (Service catalogue): Documento que elabora la organiza-
ción TI para informar a clientes y usuarios. Proporciona una visión esquemá-
tica, en términos de negocio, de todos los servicios de negocio y de la infraes-
tructura ofrecidos por el proveedor TI, pudiendo reflejar los precios de los
servicios. Esta información, acompañada de un nivel más detallado de conoci-
mientos técnicos ha de ser mantenida para su uso interno.
Categoría (Category): Clasificación de un grupo de CI, documentación de cam-
bios y/o problemas.
Centro de servicio al usuario (Service desk): El punto único de contacto dentro
de la organización de TI, para los usuarios de servicios informáticos.
Ciclo de vida (Life-cycle): Serie de estados interrelacionados, con pasos entre los
mismos, definidos y estipulados según la metodología de Procesos. El ciclo de
vida comprende el proceso de aprobación para CI, informes de problemas y
documentación del cambio.
Cierre (Closure): Cuando el cliente está satisfecho de la resolución de un inci-
dente.
Clasificación (Classification): Proceso de agrupación formal de CI según su tipo,
por ejemplo: software, hardware, documentación, entorno, aplicación.
Cliente (Customer) El receptor de un servicio. Habitualmente Gestión de clientes
tiene bajo su responsabilidad el coste del servicio, bien sea por su facturación o
indirectamente en términos imputables a necesidades del negocio.
Comité de cambios (Change Advisory Board): Grupo con experiencia en aseso-
ramiento de gestión de cambios, que puede valorar y aconsejar la implementa-
ción de los cambios propuestos. Este órgano suele estar formado por represen-
tantes de todas las áreas de tecnologías de la información y por representantes
de las unidades de negocio.
Contrato de soporte (Underpinning contract): Un contrato con un proveedor
externo que cubre la entrega de servicios que dan soporte a la organización de
TI, en la provisión de servicios a los clientes.
Control de configuración (Configuration control): Actividad cuyo objetivo es
garantizar que sólo los CI autorizados e identificables se registran en la CMDB.
Términos y definiciones 769
Esta actividad está enfocada a proteger la integridad de los datos, sistemas y

procesos de la compañía, manteniendo una relación muy estrecha con gestión
del cambio.
Control del cambio (Change control): Procedimiento utilizado para garantizar
que todos los cambios están controlados, incluido el envío, análisis, toma de
decisiones, aprobación, implementación y postimplementación de un cambio.
Control del proceso (Process control): El proceso de planificación y regulación,
con el objetivo de realizar un proceso de una manera eficaz y eficiente.
Coste (Cost): La cantidad del gasto (real o teórico) incurrido, o atribuido a una
actividad específica o unidad de negocio.
Coste directo (Direct cost): Un coste incurrido que puede ser asignado de forma
específica y exclusiva a un servicio, centro de coste o departamento. Los costes
directos son los directamente relacionados con materiales, salarios y gastos espe-
cíficos.
Coste indirecto (Indirect cost): El coste incurrido en el transcurso de la fabrica-
ción de un producto que proporciona un servicio, o un coste de gestión global
o departamental, pero que no puede ser relacionado directamente y por com-
pleto al producto, el servicio o el departamento, porque ha sido incurrido para
diferentes centros/ unidades de coste. Estos gastos son repartidos entre las uni-
dades/centros de coste. Los costes indirectos también son gastos generales.
Coste marginal (Marginal cost) El coste de proporcionar el servicio actual,
creado por una inversión ya realizada.
Coste total (Full cost): El coste total de todos los recursos usados en suministro
de un servicio, por ejemplo, la suma de los gastos directos de producir el pro-
ducto, una parte proporcional de los costes de estructura y cualquier gasto de
venta y distribución. Tantos gastos en efectivo como los gastos teóricos (no
monetarios) deberían ser contemplados, incluido el coste de capital.
Coste total de propiedad (TCO, Total Cost of Ownership): Cálculo que incluye
depreciación, mantenimiento, costes del personal de apoyo a la dirección, aloja-
miento, y la revisión de planificaciones.
Costes de producción: El coste total de los recursos directos: materiales, mano
de obra y gastos. El término costes de producción normalmente se reserva para
aplicarlo a los costes directos de producción, y por ello, habitualmente, no
incluye los costes directos de marketing o I + D.
Costes operacionales: Los costes incurridos por el funcionamiento diario de
los servicios de TI, por ejemplo los costes de personal, los de electricidad y
mantenimiento del hardware, y los atribuibles a los pagos continuados cuyo

efecto se puede medir dentro de un período corto de tiempo, normalmente
menor a los doce meses del año financiero.
Costes unitarios (Unit costs): Costes distribuidos por el uso de un componente
individual. Por ejemplo, puede asumirse que, si una caja de papel con 1.000
hojas cuesta 10 euros, entonces cada hoja cuesta 0,01 euros. De la misma manera
si el coste de una CPU es 1 euro al año y se utiliza para procesar 1.000 trabajos
en ese año, cada trabajo cuesta una media de 1.000 euros.
Cuadro de mando (BSC, Balanced Scorecard): Es una ayuda a la gestión del
rendimiento de la organización. Permite poner foco no sólo en los objetivos
financieros, si no también en los procesos internos, clientes y los aspectos de
crecimiento y conocimiento.
Disponibilidad (Availability): Capacidad y accesibilidad de un componente o
servicio para realizar su función en un momento definido o durante un período
de tiempo establecido; normalmente expresada como ratio de disponibilidad,
esto es, la proporción del tiempo en que el servicio está disponible para ser utili-
zado por los clientes dentro del horario de servicio acordado.
Documento de cambio (Change document): Solicitud de cambio, orden de con-
trol de cambio, orden de cambio, registro de cambio.
Elemento de configuración (CI): Componente de una infraestructura, o de un
elemento, como una petición de cambio, relacionado con la infraestructura, que
esté (o vaya a estar) bajo el control de la gestión de la configuración. Los CI
pueden ser muy diferentes en complejidad, tamaño y tipo, desde un sistema
completo (incluyendo todo el hardware, software y documentación) hasta un
único módulo o un simple componente hardware.
Entorno (Environment): Colección de hardware, redes de comunicación y proce-
dimientos que funcionan de manera conjunta para proporcionar un servicio
informático. Pueden existir uno o más entornos diferentes en una plataforma
física, por ejemplo pruebas, producción, etc. Un entorno tiene unas característi-
cas únicas que determinan su modo de administración.
Entrega (Release): Una serie de CI nuevos y/o modificados que se prueban e
introducen en el entorno de producción de manera conjunta.
Entrega completa (Full release): Contiene todos los componentes de la unidad
de entrega, que se desarrollan, prueban, distribuyen e implementan a la vez.
Entrega delta (Delta release): Una entrega delta, o parcial, sólo incluye aquellos
CI de la unidad de entrega que se hayan modificado o renovado desde la última
entrega realizada. Por ejemplo, si la unidad de entrega es el programa, una
entrega delta contendrá sólo aquellos módulos que hayan sido modificados o
renovados desde la última entrega.
Error conocido (KE, Known Error): Aquel incidente, o aquel problema, cuya causa
raíz se conoce y para la que se ha identificado un arreglo provisional o una alterna-
tiva permanente. Ante un caso con impacto en el negocio se realizará una solicitud
de cambio (RFC), pero siempre seguirá considerándose como error conocido
hasta su solución permanente mediante el correspondiente cambio.
Estructura de la configuración (Configuration structure): Jerarquía de todos
los CI que conforman una configuración.
Externalización: El proceso mediante el cual las funciones realizadas por la orga-
nización son contratadas externamente para la operación por terceros en nom-
bre de la organización.
Función de negocio (Business function): Una unidad de negocio en la organiza-
ción, por ejemplo, un departamento, división, oficina, etc.
Gestión de la configuración (Configuration management): Proceso que se
ocupa de la identificación y definición de los CI de un sistema, registrando e
informando sobre el estado de los CI y las RFC (solicitudes de cambio), y veri-
ficando la exactitud y corrección de dichos CI.
Gestión de nivel de servicio (Service level management): El proceso encargado
de definir, acordar, documentar y gestionar los niveles de servicio al cliente,
según sus requerimientos y con unos costes justificados.
Gestión de servicios (Service management): Gestión de los servicios según los
requisitos del cliente.
Gestión del cambio (Change management): Proceso de control de los cambios
de cualquier aspecto de los servicios, o en la infraestructura, de un modo con-
trolado, permitiendo llevar a cabo los cambios aprobados con el mínimo
impacto en el servicio.
Gestión del coste (Cost management): Todos los procedimientos, tareas y entre-
gables necesarios para satisfacer el coste de una organización y los requerimien-
tos de precio.
Herramienta de gestión de la configuración (Configuration management tool):
Un producto software que proporciona asistencia automatizada para el control
de cambios, configuración y versiones.
Hoja de especificaciones (SS, SpecSheet): Especifica detalladamente lo que el
cliente quiere (externo) y que consecuencias tiene para el proveedor de servicio
(interno), como recursos requeridos y habilidades.
Identificador de versión: Un número de versión; día de versión; o día de versión

y marca de hora.
Impacto (Impact): Medida de la criticidad que tiene para el negocio un incidente,
problema o solicitud de servicio. Usualmente se identifica con el plazo temporal
en el que no son respetados los acuerdos o los SLA esperados.
Incidente (Incident): Cualquier suceso que no forme parte del funcionamiento
estándar de un servicio y que motive, o pueda motivar, una interrupción o una
reducción de la calidad de dicho servicio.
ISO 9001: Conjunto de normas internacionalmente aceptado en relación a la cali-
dad de la gestión de sistemas.
ITIL: Biblioteca de la Infraestructura de TI de la OGC, un conjunto de guías
sobre la gestión y provisión de servicios TI operativos.
Línea base o de referencia (Configuration baseline): La configuración de un
producto o sistema establecida en un momento determinado, que recoge tanto
la estructura como los detalles de ese producto o sistema; y que permite que ese
producto o sistema pueda reimplantarse posteriormente.
Lista de cambios planificados (FSC, Forward Schedule of Changes): Lista que
recoge en detalle todos los cambios cuya implantación ha sido aprobada, así
como las fechas planificadas para tal implantación. Debe ser acordada con los
clientes y el negocio, gestión de niveles de servicio, el servicio de atención téc-
nica y gestión de la disponibilidad. Una vez acordada, el centro de servicio al
usuario deberá comunicar de forma exhaustiva a los usuarios los cambios plani-
ficados y cualquier parada que se presente en la implantación de los cambios,
utilizando para ello los métodos disponibles más eficaces.
Métrica (Metric): El elemento de medida de un servicio, proceso o función.
Petición de servicio (Service request): Todo incidente que no se considera un fallo
propio de la infraestructura TI.
Plan de calidad de servicio (SQP, Service Quality Plan): El plan escrito y espe-
cificado de objetivos internos diseñados para garantizar los acuerdos de nivel de
servicio.
Plan de gestión de configuración (Configuration management plan): Docu-
mento que define la organización y los procedimientos de gestión de la configura-
ción para un producto, proyecto, sistema, grupo de soporte o servicio específico.
Plan de recuperación/contingencia (DRP, Disaster Recovery Planning): Serie
de procesos orientados específicamente a la recuperación ante desastres,
principalmente de naturaleza física, y que son materia de la gestión de la con-

tinuidad del negocio.
Prioridad (Priority): La secuencia en la que es necesario resolver un incidente o
un problema, basándose en su impacto y urgencia.
Problema (Problem): La causa desconocida que subyace a uno o más incidentes.
Proceso (Process): Una serie de acciones, actividades, cambios, etc., conectados
entre sí y realizados por agentes determinados, con la intención de lograr un
propósito o alcanzar un objetivo.
Proceso de negocio (Business process): Un grupo de actividades asumidas por la
organización en la búsqueda de un objetivo común. Los procesos típicos de
negocio incluyen la recepción de pedidos, servicios de marketing, venta de pro-
ductos, provisión de servicios, distribución de productos, facturación de servi-
cios, contabilidad de los ingresos. Un proceso de negocio habitualmente soporta
varias funciones de negocio diferentes, por ejemplo, TI, personal, alojamiento.
Un proceso de negocio difícilmente funciona aislado, es decir, otros procesos de
negocio dependerán de él y él dependerá de otros procesos.
Programa: Un conjunto de actividades y proyectos que implementan de forma
conjunta un nuevo requerimiento o función corporativa.
Programa de mejora de servicio (SIP, Service Improvement Programme): Un
proyecto formal emprendido dentro de una organización para identificar e
introducir mejoras medibles dentro de un área o proceso de trabajo.
Proveedor de servicio (Service provider): Organización de terceros que suminis-
tra servicios o productos a clientes.
Proveedor tercero (Third-party supplier): Una empresa o grupo, externo a la
empresa del cliente, que proporciona servicios y/o productos a la empresa de
aquel.
Registro del cambio (Change record): Registro que contiene detalles sobre los
CI afectados por un cambio autorizado (planificado o implementado) y cómo
resultan afectados.
Repositorio de software (Software library): Una serie controlada de CI de soft-
ware designado para mantener juntos los que tengan un estado y tipo similares,
y separados de los que sean distintos, sirviendo así de ayuda para el desarrollo,
las operaciones y el mantenimiento.
Riesgo: Una medida de la exposición a un evento inesperado a la que puede estar
sujeta una organización. Es una combinación de la probabilidad de ocurrencia
de una interrupción del negocio y de las posibles pérdidas que pueda ocasionar
dicha interrupción.
Rol (Role): Una serie de responsabilidades, actividades y autorizaciones.
Servicios (Services): Entregables de la organización de servicios informáticos que
son percibidos por los clientes; los servicios no consisten simplemente en hacer
disponibles los recursos de ordenadores para el uso de los clientes.
Sistema (System): Conjunto integrado de uno o más procesos, hardware, software,
utilidades y personal, que proporciona la capacidad de satisfacer una necesidad
o un alcanzar objetivo determinado.
Solicitud de cambio (RFC, Request For Change): Formulario o pantalla usada
para registrar los detalles de una solicitud para un cambio a cualquier CI dentro
de la infraestructura o para procedimientos y elementos asociados con la infraes-
tructura.
Solución temporal (Workaround): Método para evitar un incidente o un pro-
blema, bien mediante un arreglo provisional o mediante una técnica que impli-
que que el cliente no dependa de un aspecto específico del servicio del cual se
sepa que presenta un problema.
TIC (ICT) / TI (IT): La convergencia de Información Tecnológica, Comunica-
ciones y Datos.
Unidad de negocio: Una división de una entidad de negocio en la que los ingre-
sos son registrados y los gastos incurridos se controlan, de forma que los ingre-
sos y gastos se usan para evaluar el rendimiento de la división.
Urgencia (Urgency): Medida de la criticidad para el negocio de un incidente o
un problema, basada en su impacto sobre las necesidades de negocio de los
clientes.
Usuario (User): La persona que utiliza los servicios de manera habitual.
Usuario final (End-User): Véase “Usuario”.
Versión (Version): Elemento identificado de un CI, dentro de la estructura des-
glosada de un producto o en la estructura de configuración, que sirve de refe-
rencia para el seguimiento y auditoria del historial de cambios. También se uti-
liza en los SCI, definiéndose una referencia específica en el desarrollo para el
diseño, revisión, modificación, pruebas o producción.
Versión completa (Full release): Todos los componentes de la unidad de entrega
que se desarrollan, prueban, distribuyen e implementan a la vez. Véase también
“versión delta”.
Versión delta (Delta release): Una versión delta o parcial, es aquélla que sola-
mente incluye los CI de la unidad de entrega que se hayan modificado o reno-
vado desde la última entrega completa o parcial (delta). Por ejemplo, si la uni-
dad de versión es el programa, una versión delta contendrá solo aquellos
módulos que hayan sido modificados o renovados desde la última entrega com-
pleta del programa o desde la última versión delta de determinados módulos.
Véase también “Versión completa”.

ISO20000 GuiaCompletadeAplicacion LuisMoran PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

ISO20000 GuiaCompletadeAplicacion LuisMoran PDF

Cargado por

Copyright:

Formatos disponibles

ISO/IEC 20000.

Guía completa de aplicación

© AENOR (Asociación Española de Normalización y Certificación), 2009

• Autores principales (Telefónica):

Tomás Hernández López (Telefónica)

• El control independiente de idoneidad técnica de los contenidos está avalado

Agradecer también a la dirección de Sistemas de Información de Telefónica que de

Capítulo 1. El camino a la excelencia ya existe . . . . . . . . . . . . . . . . . . . . . 21

Capítulo 2. Entender las Normas ISO/IEC 20000 . . . . . . . . . . . . . . . . . . . 51

Capítulo 3. El Sistema de Gestión del Servicio de TI (SGSTI) . . . . . . . . . . . . 79

Capítulo 4. Planificación e implementación de la gestión del servicio . . . . . 107

Capítulo 5. Planificación e implementación de nuevos servicios o de

Capítulo 6. Procesos de provisión de servicio . . . . . . . . . . . . . . . . . . . . . . . 191

Capítulo 7. Procesos de relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449

Capítulo 8. Procesos de resolución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535

Capítulo 9. Procesos de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619

Capítulo 10. Procesos de entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693

Capítulo 11. La certificación conforme a ISO/IEC 20000 de la gestión

Bibliografía y referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763

Términos y definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767

Por ello, no es de extrañar que encontremos frecuentemente que los departamentos

La dinámica industria de tecnologías de la información y las comunicaciones

Objeto del libro

cualquier tipo de organización que provea servicios de tecnología, tanto interna-

Estructura del libro

El capítulo 2 “Entender las Normas ISO/IEC 20000” las posiciona en el ámbito

1 Objeto y campo de aplicación 0 Introducción

2 Términos y definiciones 1 El camino de la excelencia ya exite

2 Entender las normas ISO/IEC 20000

3 Requisitos de un sistema de gestión 3 El Sistema de Gestión del Servicio de TI (SGSTI)

4 Planificación e implementación de la gestión del servicio

5 Planificación e implementación de nuevos servicios o de servicios modificados

6 Procesos de la provisión del servicio

11 La certificación conforme a ISO/IEC 20000

Bibliografía 12 Bibliografía y referencias

Figura I.1. La estructura del libro transcurre paralela

• Recorrido 2: lectura secuencial y a fondo. De principio a fin, que es la

1. El camino a la excelencia ya existe 23

1.1. Las Normas ISO/IEC 20000 son parte del

1.2. Normas, estándares, marcos de referencia

1. El camino a la excelencia ya existe 25

9001 ISO ITIL v2 ISO TOGAF

Fuente: Gartner y e.p.

Figura 1.1. Mapa de las diferentes normas y marcos de referencia

La gestión de la seguridad de los sistemas de información ha sido una de las áreas

1. El camino a la excelencia ya existe 27

1.3. Entender los entornos de normalización y

marcos de mejores prácticas (organismos de normalización internacional, organis-

• USA: ANSI Mellon

• Alemania: DIN - TÜV

Gobiernos Gobierno del país OGC DoD ISACA PMI

(UK) (USA) (USA) (USA)

ISO/IEC ISO 17799-

ISO/IEC ISO/IEC BS 25999 Prince2

Figura 1.2. Actores en el ámbito de la normalización relacionados con las TI

En el ámbito de la normalización internacional, los organismos de normalización

1. El camino a la excelencia ya existe 29

En la etapa 2, o preparatoria, se emite el borrador de la norma en fase CD. En la

Proceso de elaboración de una Proceso de elaboración de una

1. Etapa de propuesta 1. Trabajos preliminares

Fuente: ISO y e.p. Fuente: AENOR

Figura 1.3. Procedimientos de creación de normas internacionales y nacionales

A continuación, se presenta una visión general de los principales actores en este